Hey everyone, Ben here. Welcome to the Stellar Work
podcast where today's episode dives into the journey from
coding in the 90s to building AI powered platforms.
Our guest Hendrick, legendary for his role at Spotify and for
making agile methods visible to the world, shares how he
transitioned from pioneering software on and organizational
design to the frontiers of artificial intelligence.
We explore the real origins of the Spotify model, the impact
and the myths behind coding productivity with AI, and
Hendrick's adventures developing AI agents that redefine what it
means to collaborate and innovate in tech.
This episode is packed with insights about how companies use
AI, but the junior deaths still matter, and how architecture
decisions are evolving in a world of code written by both
humans and machines. So let's jump right in and learn
with and Rick Nieberg. Hello Hendrick, welcome to the
Stellar Work podcast. Thank you.
Good to be here. Yeah, thank you so much for
being here. I I saw you delve into the world
of AI some time ago, but before we dig into that, maybe we we
pause for a second and you introduce yourself to whoever
does not know you yet. I assume everybody does at some
point, but could you introduce yourself to?
Sure. So I'm Henrik.
I'm a Swedish guy sitting here just outside Stockholm, grew up
in Japan, umm, and did a lot of coding.
I've studied at a Technical University in Stockholm and umm,
I'm a soft pro guy, fund fund fundamentally.
But then I got dragged into a bunch of startups during the,
during the 90s and started getting involved in the
leadership things, building companies and startups and to
try to understand more than just how to write good code, but how
to organize people and, and, and the work which got, which was
interesting. So through that work, I, I
stumbled into what later on started becoming called agile.
So things like scrum and extreme programming and things like
that. And through that I started
getting involved with companies that wanted to work in an agile
way. So a bunch of different
companies, large and small, and I was there helping them
basically figure out how to work effectively, build better
products faster and have more fun along the way.
And of course, as a side effect, I, I, I learned a lot also.
So yeah, I spent a bunch of years at, at the Swedish startup
called Spotify, which then grew and became this wonderful thing,
learned a lot from that, published some videos and, and,
and some people started using the term Spotify model to
describe what we were doing, which was kind of interesting.
But what? Is that interesting?
Yeah. And from that I learned a lot
about scaling. And then later on I stumbled
into a Lego which, which my, which was my first kind of non
software company, which was very interesting.
Umm, and then I got back into coding again.
I ended up at, at Mojang, first as a coach, but then I, I kind
of got sucked into the, the Minecraft team and started doing
development again, development and design.
So I spent about four years, umm, doing that.
So quite, quite, you know, a mixed stuff, but and and then
now and then when AI came out, I made a complete shift into AI
space. But I think agile has probably
been a bit of a, a theme behind, behind all of it and basically
helping companies figure out how to how to work better.
Is has also I guess been some kind of a theme?
You, you passed for a second on on the Spotify model and I, I, I
always thought that you were like the the mind behind it who
promoted it. But now you said people are
using the term Spotify model. Yeah, no, I never, I didn't coin
the term. What what I did was basically
make it visible. I, I started publishing articles
about what we did and I, I didn't invent it.
I helped shape it. But there were a bunch of people
at Spotify that we, we worked together to figure out a way of
working. And then I thought, this is,
this is a cool way of working. It's a cool approach and it's,
and it's working for us. So I started making I, I made, I
made like AI started doing presentations mostly internally
as we hired people to explain this is the company that we are
trying to be kind of. And then I did a talk at a
conference and then that kind of went viral.
So then people at in Spotify said, Henrik, you should record
a video because we can't have you running around all over the
place just doing talks. You know, that's not good use of
your time. You should record a video
instead. And so I did that.
And ironically, people wanted even more talks after that.
I thought it would be like, I made a video now.
And so now I don't have to do this talk again.
But then at some point, the video was called Spotify
Engineering Culture, which is what it was about.
But then someone at some point started using the term Spotify
model to describe the approach. And then it kind of stuck.
But no, I I didn't come up with that term.
Yeah, it was. It was never an intent to create
like a model. It was more it was just a case
study. Interesting because I, I found
through my career at multiple stops, like German banks who
implemented the Spotify model through McKinsey and, and went
with that. And I was like, why, what, what,
how, why? Like what's the speech speech
that's looking at that? Yeah, I've been quite fascinated
just from a social perspective, Like, OK, so this is how models
get created, like, OK. But then to something completely
different you, is it fair to say you moved away from lean and
Agile topics and moved into AI or or how is that connected?
I would say I moved away from from coaching on agile to
coaching and training agile. I still do a bit of training.
I didn't move away from using agile.
I use agile all the time, but it, it didn't I, I, I left that
as a business, so to speak. When when the when the AI
started becoming really useful, I basically found that a new
favorite toy and. And how did that start?
Like did you just woke up 11 morning and you were like, oh,
AI coding agents? That's something that I want to
sort of jump into. Yeah, it's, I've always been
kind of interested in AI, studied a bit of AI in the in
the 90s, like in artificial neural networks at the Royal
Institute of Technology here. And I was like, this technology
is really interesting. You know, someday it'd be fun to
work with it, but of course it wasn't practical at the time.
It wasn't really useful. And then and also when I worked
with Minecraft, I did a lot of AI programming in the game,
although it's not real AI, it's more rule based procedural, but
it's still interesting the concept of creating the
behaviour that looks kind of like it's intelligence, although
through driven by software. But then ChatGPT came along and
everyone started getting excited about the fact that you can chat
with it, like just like you chat to a human.
And I was really impressed. I never thought I'd experienced
that in my life, that level of kind of skill and human language
from software. But it wasn't very, it wasn't
very useful in the beginning because it tended to hallucinate
and things like that. But then when GPT 4 came, I
started seeing a lot of, you know, research around like this
is actually starting to become really useful and really, you
know, really smart. So I decided to explore this.
So I, I took a week off and just kind of went off to my cabin and
just turned off the phone kind of and just started tinkering
on, you know, all day and all evening with this weird
technology and tried it for stuff, tried it from, you know,
coding, tried it for reviewing articles for planning workshops.
So probably about half of my, my, my experimentation was with
coding and half of it was other stuff.
But then I was really blown away.
It become like a kind of, in a way a life changing moment
because I started seeing the potential.
It wasn't perfect, it had its flaws.
But when I realized how to use it and I started discovering
techniques that nowadays people would call prompt engineering or
context engineering, then I was like, OK, this is, this is the
most powerful tool I've ever seen and it's only in its
infancy. So then.
So then I decided just to work with it full time.
What have you built during that time when you when you started
playing around with it? So the, the first thing I built
was actually a chat bot, which then became a platform for chat
bots. The chaplet I built is called
Egbert. Egbert is a bit of a, a persona
that I invented, a sarcastic little kind of cartoon
character. And I and I made a virtual
Egbert and then I added him to my Minecraft server and to my
Discord server with my friends. So Egbert would kind of comment
on what's happened and what's happening inside our Minecraft
server and on Discord. And then I kept adding stuff.
So I started adding memories. Egbert would remember things so
he can recall things using techniques that now people would
call rag or retrieval augmented generation.
And Egbert became my little, you know, platform for
experimentation. And then a friend was like, Hey,
I want to add another persona. So then I made the platform more
generic and added the ability to add any kinds of of, of
characters, which is, I guess that the embryo of what I work
with now, which is a agents. But it was pretty fascinating to
see like how kind of live this character seemed.
You know, you would log into the Minecraft server and he would
say some sarcastic comments like, oh, it's you again.
Are are you going to fall into a hole today like you did
yesterday? Right.
And then and just had these long arguments with them.
Very fun. But the, but then also during
that whole experience, I used, I used a lot of AI for, for
writing the code for that platform.
And I was really blown away by the fact that I could write such
a so, so like 10 times faster in terms of development.
So just from a productivity perspective, I was like, whoa,
this kind of changes the whole equation.
Yeah, you're just jumping into the next question that I that I
prepared and I was wanted to ask you where do you see the use
cases in company beyond like let's say summarizing a bunch of
emails, is that generating code? Is it?
Is it that? I I think generating code is
probably the the strongest use case right now.
That's where the technology has come the furthest in terms of
being like useful right now. But there's a lot of other use
cases now that are that are kind of starting to reveal
themselves. But, but even the basic things
like summarizing a meeting is, is of course a very useful use
case. But what we've noticed and the
reason why I started the, the company I work for now
abundantly is is because we noticed that AI becomes a lot
more useful when you give it some level of autonomy and let
it do stuff on its own and not just be stuck inside a chat.
So example of use cases there. So we made a platform where you
can build colleagues, essentially AI colleagues that
have a job and a mission and tools and they can do do things
on their own, but within, within a scope that you give them.
So typical things they would do then is for example, screening
an investment company we work with.
They need to look at, they need to do research for thousands of
companies every year. And this agent just takes that
spreadsheet and does, you know, parallel research tracks for all
1500 lines. And and it looks at the website,
does research, digs online and does follow up research and then
basically classifieds it into, yes, this company is, is
interesting for you to invest in.
This is a no, this one's a maybe.
So those kind of things or things like a triaging support
tickets or yeah, there's just so many different use cases where,
you know, lower level work that, that kind of waste people's
time. And by by having an agent do
things like business intelligence research, right,
then that frees up time for people to work kind of on higher
level stuff. So that's, that's, that's
there's a lot of use cases popping up around that.
But what one of one of the simple ones that all companies
need to find is basic research. So what, what, what are our
competitors doing? Have there?
Are there any new laws being, being being created within our
space? I mean, any changes, any, any
news events that that is relevant for me and my team.
So go out, look for that, proactively alert us to what we
need to know in a format that's useful to us.
So not just a spammy newsletter, but very targeted like this is
something that should be on your radar.
Interesting. But maybe let's come back to to
the AI coding. There were a bunch of case
studies that showed you could achieve like like that.
I think it was a get up case study that that published like
you achieved 20% performance increase when you use coding
like AI supported or AI guided coding.
I think it was. That study is pretty old by now,
but do do where do you think those performance indicators
could go? So this is something it's, I'm
kind of fascinated by it because since I'm, I'm living this now
since the past two years coding everyday with AI support and
before using AII did coding at a professional level on and off
for about 30 years. So I have the comparison kind of
before and after. And for me it's easily 10 times
more effective, sometimes 20 times or even 100 times.
It's, it's ridiculous on average.
So in some specific cases, sometimes I have to do things
myself or so worst case it's like it was before, but then
suddenly I can do something that would have taken me a week and I
do it in one hour. So, but then what I've noticed
is that it's quite rare to have that effect.
It's, it's only like most people I meet don't see that effect.
And, and, and, and I've been thinking a lot about why.
And I've worked with a bunch of teams with this.
And what I, what I realized is you need a number of components
to get that level of productivity improvement.
You need a really good model. You need a really good tool.
So by, for example, a really good model is clawed for Sonnet
or clawed for Opus. A really good tool is cursor.
I would say nothing compares with it right now.
I can develop an environment and then you need really good
skills, both like personally, how to use it.
What in what situations do I use AI?
In what situations do I trust the AI well, versus carefully
review the code And in what situations do I give, do I give
it a, a big job versus slice into tiny increments?
And there's all this kind of skill effects.
So how do I phrase a good prompt?
What context do I give it? How do I what do I do when it's
when it makes a mistake? So all that stuff is a skill you
build up over time. But if you have really good
models, really good tools and you've built up this this skill
set, that's when you get the kind of radical improvements,
which which makes the 20% improvement sound like really
like what that's it's way. It's way beyond that.
But I think if you're, if you're new to it, you're not really if
you're not used to working in this way because it is a
different way of working. So if you've been coding for a
long time, coding with AI is different.
It's a new way of thinking and until you to until you grasp
that the improvements will still be there, but it'll be maybe in
the 1020% range because it's just it's like having a junior
assistant helping you with some very basic tasks.
Yeah. Can you elaborate a little bit
why why it's so different or? Well, for example, normally if
I'm without AI help, if I'm going to solve a problem, I need
to think about the problem is I'm going to solve and I need to
think about how am I going to write the code.
And I'm in my mind is very much on how am I going to get this
code to work? Both AI, there's this meta
thinking all the time, which is what kind of complexity is this
problem? What kind of context would an AI
need to solve it? So it's like an AI first
thinking my, my default goal is AI should write every single
line of this code. And then there's this reasoning
happening all the time in my head, like a separate thread
thinking about how much or how little do I do I give this
person. So I would say you can compare
it to coding yourself versus mentoring a new employee who
joined your team. You're going to have a
completely different mindset. And some you want that employee
to write as much of the code as possible, but sometimes you need
to help them, give them feedback.
And sometimes you need to write the code yourself and explain to
that employee. And if that employee makes the
same mistake several times, you need to take a step back and
say, what is that person lacking?
What context do do they not have?
Or is it, or is this kind of problem beyond their skills?
So yeah, it's it's a different kind kind of mindset.
You, you mentioned that you wanted to write 100% of that
code that I mean, it sounds crazy to me, like I'm a hardware
guy, probably I don't understand coding as well.
But having this, I thought it would work in a way that you
would prompt something and you would get a bunch of code and
then you would like sort of debug it or you would like play
with it and then push it to production.
But you seem to work in a different way, like you would
try to give it as good of a context that it generates 100%.
Yeah, it's, it's like a it's a goal, but the goal is not always
achieved. But by by having that as a goal,
it forces me to think in a certain way.
It forces me to break down the problem in a really good way.
And it and that's where Agile comes into play, right?
The ability to write a good user story, the ability to split it
into small slices that each are testable.
That skill gets comes into play when you're thinking about what
would the AI need to solve this problem.
But in practice, what we find is if you imagine a scale like a
develop, I like to draw a picture of, I call it the
developer laziness scale, right? So it's from 0% to 100%, so on,
on the 100% and it's 100% laziness.
So you, you write a prompt and then you go make some coffee
and, and then when it's done, you just push to production.
Don't even look at the code. So that's what people sometimes
call vibe coding, right? But then moving left on a scale
we have like let's say 80% laziness is a Reddit prompt.
AI writes the code and then I just skim it high level and just
see if anything looks weird. And then and then I push it.
So AI writes. So basically AI does most of the
stuff, but I'm at least aware of the code.
And then 60% right would be, or like let's say 50% AI writes the
code and I carefully read every line and, and, and almost always
make a few tweaks. And then going more down to the
down, down, down the scale, maybe 2030% would be AI writes
the code, but I just use that to get some ideas.
Then I write it myself. And then of course, the case 0%
laziness. I write every line myself.
And I, you know, I Google around, go to Reddit and, and,
and stack Overflow to figure out things.
And the key, the key skill I think now is as a developer is
you need to master all parts of that scale.
You need, you need to be able to write code yourself because
sometimes AI will fail unless you're building a very simple
product. But if you're building something
complex or a platform, you need to understand what's going on.
You need to be able to write the code yourself, even though it
might take you 20 times longer, But you also need to be able to
write, craft a good prompt. And, and the most important
skill, I think is the meta level skill, which is determining
which part of that scale I should be on right now.
Does that, does that make sense? And, and I find it if, if you
can do that, that that's when you really get, you get the
best, you get the best everything.
You get AI generating the code when it can, but you also don't
get the technical debt, which you can get if you just do fire
and forget and don't even check the code yourself.
Yeah, I think it's really interesting because it reminds
me of Q1 this year when all the tech CEOs claim that so and so
percentage of their code is written by AI.
I don't know if you, you, you follow the press there and I,
but I think it was Microsoft and Satya started with like 30% of
our code is written by AI. And then Mark Zuckerberg went
down with like 50% of our code is written by AI And traffic CEO
is like by the end of this year, we have 90% of AI mine.
Is bigger than yours. Yeah, I'm just waiting for Elon
Musk saying 200% of the code is written by AI.
Yeah, The funny thing is, if you asked me, like how much of our
code is written by AI, can't answer it because it's like if,
if you're in a group of people doing mod programming, how much
of the code was written by Joe? It's a collaboration, right?
Even he wrote some code. I looked at it, I made some
changes, I wrote some code. So, so AI to me is just like a
colleague. It's it's a team member.
And just like with any team member, you kind of split up the
work. Sometimes you work together,
sometimes you review each other's code.
So it's, it's not even a, a relevant question.
So I would say in my case, I would say how much is AI
involved in the coding? I would say it's involved in
probably 90% of all code in one way or another.
But then how much is actually written?
Well, that to be different, right?
Case by case. Yeah, oh gosh, I I found a very
stupid question that I got here on on my prep sheet.
They're they're they're is. It possible?
Is it possible to vibe code lovable at lovable?
Wow, OK, here's my guess. I've used lovable quite a bit
and my guess is no. OK.
In fact I would say with certainty no, not yet.
But in the future almost certainly yes.
The question is how long that is a future.
Don't know. OK.
OK, a really interesting question, but yeah, lovable is
is incredible, but it, but it's optimized for fairly simple web
apps with a front end and a database.
And for that it's it's amazing. But to build an actual platform,
then I would say at least at the moment it's you really can't.
OK, have you seen, Do You know the Pragmatic Engineer podcast
or or newsletter? No.
So it's a really, really cool newsletter from Gergley Auros.
And in one of his interviews, he interviews Farhan Tawar from
Shopify and they would go through the, the history of AI
at Shopify. They were one of the, the beta
testers from Microsoft Copilot even before it was called
Microsoft Copilot. And they have some interesting
things going on there. So, and, and I'm curious what,
what you would say about that, because let's start with this
one here. They use AI in interviewing
processes like when they hire someone, regardless if if that's
an engineer or it's a manager, they would have a coding
interview because they claim hey with AI everyone should be able
to code now. Right.
They would, I I didn't understand they would use AI.
How? They would give you a like a
coding interview when when you apply a Shopify, even if it's
for a senior management position where you're not involved in
technical details. OK, so so they want to see if
you're able to basically vibe code.
Yes, correct. How do you feel about that?
Both positive and negative at same time.
I'll explain why. Umm I I think everyone should
know how to buy code. At my company.
Our CEO is coding in our platform.
He's not a coder. I I set up an environment for
him. So when he wants to make a
change in our platform, mostly not customer facing stuff, it's
mostly internal admin stuff. But he needs some, some graph or
something that it's over usage of our platform.
He doesn't come to us. Instead he just makes APR.
And in the simple cases, we just, we just, you know, merge
it sometimes we look carefully. It saves a lot of time for us
and it also empowers him a lot. He doesn't have to put stuff in
our backlog and hope we get around to it right.
So it's, it's amazing. So so my my goal is that
everyone at our company will have a set up so they can code
but to during an interview I think doesn't make sense.
What Why is it important that someone already knows how to
vibe code before they even join your company?
You're going to lose a lot of potential people that way.
The idea is to. To you know, it's, it's great
that you encourage that, but I wouldn't filter someone out
because they haven't already done it.
However, I would check their attitude.
Are they willing to learn this? Are they interested?
Got it, got it. So the the way I I understood it
was that you would be able to optimize your work flows through
AI and code yourself some little agent helpers that help you
along doing your job. Yeah, yeah, I think you're kind
of like everyone should know how to use Excel.
Yeah, right. Yeah, and this is Excel, right?
You should be able to use this as a basic tool.
Like I need to do some calculation.
Don't go talk to someone else. Set up a simple spreadsheet.
If you're going to build something more advanced, you're
still going to need someone to help you do it probably.
But for simple things, knowing how to use Excel gives you
superpowers. And I think in the same way now,
taking at the next level, knowing how to use, knowing how
to write code for simple tasks with AI help, it gives you
superpowers. Maybe let's take a little bit to
the hiring process, because another question that almost
always pops up is whether do companies still need junior
developers or can they be replaced by AI agents doing the
coding? So I, I think the, the junior
senior thing is really interesting.
I think that question is timeless.
It's always been like, have we have we ever needed junior
developers? So I'm going to throw that back
at you. Even without AI, why would you
ever hire a junior developer? To get some if.
You can hire a senior one What? To to get some cheap volume.
Yeah, it could be. It's there's usually a number
reason I feel people do it right.
One is that, well, you know, your senior developers are going
to die off at some point. You need to get some younger
people in also. They come in with some fresh
perspectives. They tend to be faster at
learning new things, a little more curious sometimes.
Sometimes senior developers are really productive, but kind of
stuck in their ways a little bit.
There's all kinds of reasons that even as a senior developer,
you will improve your skills by helping a junior.
All those things still still apply with or without AI.
So I think the, the key thing is not whether it's junior or
senior, I would say, I would make sure that everyone that's
on my team, regardless of skill level, are, are using AI as part
of their toolkit. And and that's, that's the
important part, but they might use them in different, in
different ways. So I'd rather have a junior
developer who really leans into using AI help versus a senior
developer who doesn't. However, ideally I would like to
have both because they bring different things to the table
just like they always have. So yeah, I'm, I get a little bit
concerned when people are like, yeah, we don't, you know, we,
you know, we, we, we, we don't have any, like junior developers
won't have any job. Maybe that's going to be true.
I don't, I don't know. But I really, I really hope not.
So I think it's that would be really sad.
I mean, in the in the last quarter we saw a bunch of tech
layoffs and positions that didn't get filled, filled and
less jobs being put out on the market for developers.
So the times were were really rough and everyone was claiming
like, hey, this is the AI coding is the reason for that
development. And looking at the numbers, now
that they publish, there is a slight uptrend in the
Magnificent 7 and they're hiring more and more engineers, not a
not big numbers, but the the trend is going back up again.
Yeah, Yeah, some thoughts about that.
One is it's easy to make the, you know, mistake of causation
versus correlation, right? You know, is it because of AI or
not? It's hard to know for sure.
But if you look historically, what AI does, it gives as a
developer, as a junior developer, I would say as long
as you don't define your job as writing lines of code, then
you're in a probably then you're probably fine.
But but if you define your job as the person who types the
lines of code, then yes, that job is gone.
It's disappearing very quickly. But historically, we invent the
technologies that have, you know, vastly improved the
productivity of developers by going from writing machine code,
assembly code to writing higher level languages.
And now with modern ID ES that do code completion, you know,
one shortcut, refactor and read something through the whole code
base, automated testing, even before AI, there, there are
several step changes in, in the software development community
that made everyone like, I would say at least twice as
productive, but maybe even more. So you'd think that, OK, so now
that developers are twice as productive, we only need, you
know, have as many developers. Now we can fire all the juniors.
And why do we need them? Because we have these modern
development environments, but the effect has been more
developers. The software industry has always
been growing. So, so, so in that sense, from a
macro perspective, I don't, I would, I would be surprised if
this is the end of development. I think that trend is going to
continue. We made people more productive.
There's going to be more people doing development than ever.
However, maybe not many people that have that as their defined
specific job. And instead it's everyone is
coding. And what real kind of
professional coders do is not focus so much on writing the
code because AI is better than that.
In the same sense that, you know, in the past, you need to
worry very, very much about allocating memory, about garbage
collection. That was an important part of
your skill. But now compilers do that better
than humans. So you don't work, you work at a
higher level. So I think as long as you as a
developer are thinking in terms of I'm a problem solver, I solve
problems with software and AI is 1 tool in doing that, then then
then you definitely have a lot of value to to bring to bring to
the table. And part of it is, I think what
you mention is, is pretty well summarizing the Jevons paradox.
What's that? That is, when something takes
less resource to create, there is a higher demand for that.
Right. Yeah, that's probably part of
it. Another technical question
maybe, and you have to explain it to me like I'm a 5 year old
because as I said, I'm a hardware guy just strolling
around in a software world. What about architecture?
It it seemed to me that some, at some point the AI is decided
making architectural decisions for you and overhauling them.
Whenever it I think it is the correct word for that, it thinks
it it should be overhauled. So so how is it?
How is it possible to not own the architectural plan behind it
or or is there a way to do it? Yeah.
I, I think what changes at least the how things are now, I find
that in, in like for example, for us, we are in 100% control
of our architecture. We're not going to outsource
that to anybody because that's a core part of our business.
So what what happens now is we spend a lot more time in
architecture than we ever would have done in the past because we
have time for it, because we're not as much stuck in the weeds
with, with getting the code to work.
But I think it's a really a really important part of the
decision as as a developer is deciding what part of the
architecture do you care about? And then you pay attention to
that and now you have the option to outsource some part of the
architecture. For example, maybe I haven't,
let's say I have an admin interface, an admin web.
Where would you use internally to kind of follow up on things
on what's going on? And that's maybe not a crucial
part of our business. It's not customer facing.
And if an AI, if I can use an AI to, to build that in a day, the
whole thing, then as long as it works fine, maybe I've, I, I may
decide that I don't care about that architecture.
I can look at a high level, OK, it's a front end, it's a back
end. It's a react thing.
Sure, it's using a few frameworks, but it's working.
And I don't really care why or how that's a choice you can
make. It's not always the right
choice, but it's also not always the wrong choice.
I think it's the key thing is to kind of think of it as you
decide which parts of the system that that you want to be in
control of and it's in it's a it's a continuum.
It's not like either you control it or the AI control.
It's, it's you decide how much. So maybe it's this.
I complete, I control completely this I control control mostly
myself, but I use a lot of AI help that part.
The AI does most of it, but I'm at least involved.
I'm I'm at least aware of the architecture and this part of
the black box. I don't care as long as it
works. I don't even want to look at the
code or the architecture. But of course, over time, this
is shifting because as AI improves in capability and it is
improving at pretty much an exponential rate, it's, it's
quite mind boggling. There are things I can do now
that I wouldn't dreamed of doing for, for a year ago.
So it's kind of like you bought this, you, you hired an
employee, but that employee is getting smarter all the time.
And as they get smarter, you can give them a responsibility.
So that's also part of it. I feel a very similar question
is regarding do you run with rather micro services to create
a more monolithic structure in your product?
And when I first encountered like, OK, there are AI coding
agents now, so I thought that we would lean towards like the
throwaway monolith and just vibe coded whatever we want from
scratch. Yeah, this is really
interesting. And I, I think that really is
one of the key parts of the decision.
Do I care about this code, right.
And, and I think, I think there's a very clear complexity
ceiling for how, how much you can get away with that.
And for example, at the moment, I would say if I need to build a
carpool sharing app or something, right?
Or if I want to build something like, yeah, a meeting
coordinator, find the right time for everybody based on
everyone's schedules, fairly straightforward app, right?
It may, it may, it may be it would have taken a few weeks to
do manually, but with lovable or cursor, it would be maybe, you
know, an hour to get the first draft up and then maybe a day or
two to get to really work. Well in that kind of context, I
would I would consider it throwaway because it took one or
two days to build. So I can make a new one, you
know, next month if I want. So the code doesn't really
matter. But when you get beyond a
certain threshold, it quickly turns into this is actually code
I need to maintain. And then architecture matters a
lot. And it pitfall that a lot of
people fall into is not knowing that.
And if and if you don't, if you don't have development
experience, you really can't know that.
It's, it's hard to know where that limit is.
But with development experience, you, you have a, a feeling for
it. Like, OK, at this point, I do
need to do, need to care about architecture.
And then it's easy to run into this problem where AI gets it to
work, but it keeps adding to your pile of, of technical debt.
It keeps adding duct tape and stapling stuff.
And and then you finally get to this product where, oh, wait a
SEC before I can add a new feature and 10 minutes of vibe
coding. Now it's going to be, you know,
3 hours of swearing because AI keeps making a new mistake.
And it's not because AI isn't competent, it's because you've
built the mess and even a human would have the exact same
problem. So that that's really important.
So, So what what I find is like in our case, we are a tech
company and we have a platform that is part, you know, a core
part of our business. So quality matters are locked
and there I find that it's really the same principles as
always as before, you know, modular architecture, clear
interfaces, minimizing, you know, a coupling and and
thinking about dependencies. All those principles are, are
the same and maybe even more important than ever, because if
you have a solid architecture nowadays, the, the best AI
models will follow that architecture in a really good
way. In the past, a year ago, they
would tend to just add stuff on top.
So your, your architecture would kind of deteriorate.
But now I find that it, it, it keeps the architecture and even
sometimes improves it. But if it, but if, but if you
have a monolithic mess from the beginning, it's really hard for
AI. It's possible to change it, but
it's not going to do it by itself.
It's going to tend to just add more stuff on top, very similar
to what humans do, right. So I'm going to find now that
that kind of architectural patterns that seem to be best
for AI power development is Mona, Mona repos.
So we recently went from a, from a kind of a micro service
architecture into from, from a deployment perspective, it still
is micro service, but in the coding environment, it's, it's a
Mona repo because then it's a lot easier for the AI to see the
big picture. And it, it really improved our
productivity a lot. When I could ask right one
prompt that say, make this change and it examines the front
end and the back end answers a answer is being and goes, OK,
here's all the changes we make in all the places.
Test everything and and then it's ready to go.
Well, in the past, I'd have to jump around between different
repos and it'd be a lot more, a lot more work.
So, yeah, the, the, the good old architectural principles that
we've always, you know, the timeless architectural
principles are still relevant, more relevant than ever.
The one thing that maybe changes a little bit is that it becomes
even more useful to have things like a Mona repo.
Yeah, having that, aren't you afraid of let's say so there was
this case about from from Jason Lemkin, who who runs a a company
solely built on vibe coding. He used Replit for it.
I don't know if you heard about that case, but during a code
freeze that that Replit AI deleted the whole database that
was in production. Yeah, I didn't hear.
I'm just scared that those things are going to happen.
Probably yes. It happens also with employees,
right? It it's, it's a, it's a thing
that sometimes happens. People make mistakes.
A is they, I find they're less likely to make mistakes, but but
they can be given a context that pushes them in the wrong
direction. Or if you, if you use a cheap
model, then it may just make dumb mistakes.
So part of the the work, and this is, I guess, an example of
why it's different, right? It's you thinking about, I just
got this intern right. What environment should I give
the intern? Should I give the intern the key
to our production database with write access?
Should they be able to delete it?
And I would say, if you hire an intern and that intern deletes
the production database, whose fault is it?
Is it really the intern? What do you think of?
Course not. Not someone decided to give the
intern the ability to erase the production database.
Why would they do that, right? You didn't create a safe space
for that intern to make mistakes.
So I think it's really important to have the same mindset.
And the way I think of it is there are there are reverse
there, there are mistakes that are reversible and mistakes that
are irreversible. Really think about that with
your AI setup. So making code changes is
reversible almost always if you have version control system,
which you do, right? So it's fine if it erased all
the code, you just undo, right, Revert.
So that's pretty safe. But if the tools like Cursor can
also run shell commands, so they can do stuff like get commands
and stuff and get commands are pretty safe too.
They're mostly reversible as well.
But if it's going to start, you know, installing stuff in your
operating system, then it might break something.
So yeah, you need to think about that.
I, I would never give my cursor installation production in
access to the production database.
It shouldn't need it, so I would say that would be a a mistake as
a user to give it stuff. I I I don't think it would
accidentally erase it. You'd have to go quite far for
that to happen. But the key thing is why even
take that risk? It doesn't need access to the
production database, at least not write access.
Yeah. All right, I'm, I'm wondering
like you're, you've been into the space for quite some time.
How do you, how do you keep up with all the trends?
Like I'm I'm interviewing you now but I seem like everything
seems to happen so fast that we could do another interview
within 1/4 probably and have a bunch of new topics over.
Yeah, it's, it's crazy the rate of of like technical
improvements. But personally, I just given up
on keeping up kind of even even like a couple of years ago.
I'll just conclude that, you know what, I'm going to stop
trying to keep up because it's just stressful and it kind of
impossible. So instead, there are, there are
a few things that I kind of try to keep an eye on.
I think that's what people need to do.
They need to decide what are the, what, what subset of this
space am I interested in? So in my case, you know, the,
the, the foundational models clawed and, and, and, you know,
open AI, you know, when a new model comes, I will, you know,
look into that. Improvements to development
tools such as cursor. I'll definitely look into that.
Or new patterns for agent prompting.
But, you know, then a new video tool comes along, a new video
video generation tool comes along or some new, you know,
some new platform. Yeah, I just accept that I won't
know what's going on and then hope that somebody's going to
poke, poke at me and say, Henrik, you should check this
out. Maybe it'll hit my radar.
But yeah, there is a continuous sense of FOMO a little bit that
I think anybody working in this space has to just get used to.
Yeah, probably. When do you think all of this
will with HAT, let's let's say maybe focus on on AI assisted
coding or or AI coding. Where do you think will this HAT
within the next 12 months what we're going to see?
So just looking at the trend. It seems that they're just
improving all the time and there's 2 levels.
There's, I guess there's three things that are improving all at
the same time. 1 is the foundational models themselves,
such as Claw, GPT, etcetera. The second is the tools that we
use to access them, For example, Cursor, which is a wrapper, a
product that sits on top of foundational models.
So it's a code editor, but there's a lot of prompts in
there and a lot of kind of magic going on where the developers of
that tool are, are doing things to make AI aware of your whole
code base, which is magical, but, but you need both.
So if you just go to Claude and copy paste some code or go to
GPT and copy, copy, paste code, you get a very limited
productivity improvement. But using a tool like Cursor, it
just kind of understands your whole code base in some weird
magical way. And that's of course going to
keep improving as well. Cursor gets updated every week
and there's of course Cursor competitors that are starting to
catch up gradually. And the third thing that's
improving is, is the engineer's ability to understand how and
when to use these tools. So I think as, as, as a just
looking forward, I think it's just going to be AI is going to
be able to take on more and more complex coding tasks.
We're going to be able to give them bigger and bigger jobs.
For example, nowadays I sometimes do things like write
one prompt and then we'll have lunch and then come back and it
made a major change in our system.
And I would review it at a high level, ask for some small
changes and then push it to production.
But the work it did while I went while I went to lunch would
basically be a whole week of, of both coding and meetings.
And that was not possible to do for, you know, half a year ago.
Then I would have to slice it and work in smaller steps.
So I think things like today you can't go to a legacy banking
system and say, can you rewrite this whole COBOL thing in to C#
and and and, but maybe in the future, like you can do that
with some parts of it, but you couldn't just do the whole
thing. But in the future, my guess,
maybe not within 12 months, but maybe, you know, maybe a bit
longer. I think it would be perfectly
feasible to basically write a prompt and saying rewrite this
whole damn thing using C#. And as part of that, there'll be
first discussion about how the work will happen.
So it would it would maybe say things like, how about if I
first write really good test coverage in the existing system
and then I will let you know about any key trade-offs that
need to be made. And we'll have points where we
check in and we'll make an incremental plan for how to test
this and roll it out. So we'd have a discussion
exactly as if you hired A-Team or a company do this job right,
you hire them. The mission is rewrite our whole
system from cobalt to C#. Sure, that's the one prompt, but
of course it's going to be touch points and check insurance.
But that company is driving the work.
And I think that's going to be, we're going to gradually
shifting into more and more of that.
And then again, it's as a as an engineer, it's up to you to
decide you, you need to be like a good customer.
You need to decide what, what job am I giving the AI?
How am I going to follow up on it and which parts do I want to
understand? Which parts am I willing to
trust the model? That's going to be really
important. But yeah, the the trend seems
very clear that the the models are just improving really
quickly. When people want to learn more
about this and when people want to sort of maybe have questions
or reach out, what would be the best way to to get in touch with
you? So getting in touch with me is a
little bit hopeless because I, I basically focus mostly on, you
know, developing our company and our our platform and very rarely
check e-mail, but sometimes on social media.
So on Twitter and LinkedIn, I'm sometimes actor there it is.
It is fine to drop an e-mail. My e-mail address is on our
website that a bundle. I usually read emails, but I
don't always respond. So it depends a little bit on,
on on the context. But yeah, generally speaking,
I'm pretty lousy at offering, you know, kind of free support
to the world. I, I, I do post things sometimes
and if people write comments or questions, I will sometimes
respond in that context. I like to engage in that way.
And what I like about that is if someone sends me an e-mail and I
answer, it's only us 2. But if I post a a topic and
someone writes a comment and I answer there, then it's kind of
in public. And there's a lot more use out
of that than than. Individual awesome and thank you
so much for jumping onto this episode with me.
It was really, really interesting and looking forward
to your work at the bundle. Cool, thank you, this was super
interesting. Likewise, bye.
Thanks for tuning in and being part of today's deep dive with
Hendrick Nieberg. It's always a privilege to share
such inspiring stories of tech transformation and learning.
If you enjoy this conversation, don't forget to follow and join
Stellar Work on our social media channels, LinkedIn on Twitter,
Instagram and Blue Sky. Gosh, join Blue Sky where
discussion continues and you can connect with other industry
leaders. Your feedback and stories shape
the podcast, so make sure to reach out, leave a review and
stay tuned for our next episode. And to them, keep experimenting.
See you soon. Bye.