# AI Agent Harnesses and MCP Strategy for CTOs

**Podcast:** alphalist.CTO Podcast - For CTOs and Technical Leaders
**Published:** 2026-09-03

## Transcript

Hello friends, this is the Alphalist podcast.
I am your host, Tobi.
The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company.
We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast.
Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events.
Just go to alphalist.com to apply.
Welcome to the Alphalist podcast.
I'm your host, Tobi.
And I thought a lot about today's episode.
I had some holiday on the way and it was like, yeah, really exciting because the thing I...
couldn't stop chewing on after I talked to today's guest is that right now, like every CTO I know is quietly building the same thing, their own agent harness.
And some even spun it a bit further and now call it their own little software factory.
Some, the ones who actually want to sell the product, call it a software dark factory.
And I kind of feel reminded a lot of the 90s when everyone was quietly building their own ticketing system or their own throwaway CMS.
And my guest today, I guess, has a pretty good insight on what might be the right direction or not and also has a very own setup.
The interesting aspect is that he's, yeah, he made quite, a career in software, I'd say.
He worked for Meta.
He actually is behind or one of the guys behind the Mercurial versioning system.
I don't know who knows that here.
And now he's a member of the technical staff at Antrofic.
His name is David.
He's German.
originally from Munich, studied in Munich, to Munich, I think.
So the best you can do as a German working in software.
And I was super excited to talk to him.
David, welcome to the show.
Hey, welcome.
Thank you so much for having me.
I'm excited to talk about this.
That's great.
So maybe we start, like before we dive deeper on MCP, which you...
tend to develop, right?
Like you're one of the people behind MCP.
I'm one of the co-creators.
Yeah, I'm one of the co-creators.
One of two people, yeah.
That's amazing.
Before we talk about like all the do's and don'ts, MCP versus CLI, what to automate and whatnot, right?
Like the stuff you love talking about.
Right.
Let's maybe like talk about your nerd path, as I always call it.
Like why did you start digging into computers when you, or why did you get lost in computers at the age of 13?
Why did that happen?
Yeah, I think it's a good question.
Around 12, 13, I got into, as many kids would do, got into computer gaming.
And with part of that, I have a bunch of friends in school at the time.
who would like to do computer gaming.
And eventually you're going to be like, oh, but we want to do some stuff.
We want to review games and we need a website.
And so you're going to go and start building websites.
And sooner or later, like this is like the late, the late nineties, you discover all these websites.
They have guest books and counters and things that are like, you know, nostalgia now and a forgotten path, but past, but it's.
It was there.
And you're like, okay, how can I do this?
How can I write my own guestbook?
And you can integrate a guestbook from like a website and pay them a euro or whatever, a mark at the time, whatever, for that.
But you could also just go and learn PHP.
And so that's what I did.
And I learned PHP maybe when I was 13 years old, so somewhere in the late 90s.
And through that, Two things happened.
I, on one hand, got some summer jobs around PHP development where some nifty businessmen took young students, had them pay what was for the student a lot of money, but in the industry, very little money, have them develop software and sell it to someone else.
And I was quite happy doing that.
I also, over via PHP, I got to know a guy called Albrecht Günther at the Munich PHP user group.
And he was just about to become part of a small, but very, very proliferant agency in the PHP space called Mayflower, where I started to work at probably the age of 16, part-time.
And I did a lot, a lot of learning there.
And throughout that, like...
just having always people around you mentoring.
You just love this environment.
You love that you can, as a 16-year-old, you can go and create stuff.
And so over the time, you tend to spend time less playing football outside and more in front of the computer to the point where maybe the parents are getting worried.
They're happy now, but at the time, I'm sure they were married.
Yeah, yeah, yeah.
Let's not talk about ISDN phone bills or so, right?
Oh, exactly.
We all had the situation.
We all had the situation.
There was a fun little thing in Munich where you could dial in via the Munich network and you can play local area network games without the internet connectivity.
So you can use the pirated versions.
I ranked up like 700 euros or something.
My mom was not happy.
I got grounded for a while, for sure.
I still remember the day when I had the game MDK.
You remember that?
That was great phenomenal at that time.
And I put it on floppy disks and brought it to school.
Two days after another, the guy had to return me the floppy disks.
So that was a great time.
That's what we did.
You sit there, 30 floppy disks.
Inside disk one, inside disk two, inside disk three.
Different times.
But that's how I started loving computers.
I had computers from very early on.
I was very lucky to have an older brother who had computers very early on at the internet very early on.
So I was very lucky and such that I literally grew up with the internet.
I grew up with programming.
And so it's just like the path that has always been...
there for me.
And I think having the ability to have like a, like a generalized machine in front of you that you can just program in the way you want, I think it's just really awesome and something incredible fun that like...
What, 25 years later is still just as much fun.
And it's changing a lot right now, right?
It's always changing.
Yeah, but I mean, the biggest change is, I'd say now.
I mean, the biggest change after the center tech, let's say.
Yeah, I agree.
But yeah, let's talk about that later.
And why did you start then to program?
Like, what was your first aha moment with programming?
I think it was really writing a guest book for my own website.
In PHP, I helped with a little music website as well, doing stuff there.
Very painfully learned the need for databases instead of files.
Flat files.
Yeah, and a bunch of other things.
And so I just got very lucky, just really love engaging with people and helping people out.
doing something meaningful.
But this was really, for me, this web development was quite early.
A lot of my friends at the time went through graphics programming and other bits and trying to build games.
That never happened for me.
I was always the person who wanted to write interactive websites.
And how did that spin into, hey, I built my own version control system?
How did that...
developed a tendency to maybe build the infrastructure behind stuff?
I mean, MCP is also kind of what powers the tooling.
That's a good question.
In the PHP time already, as I became better in programming and did more stuff, I became obsessed with the tools around the programs rather than the result itself necessarily.
Much to sometimes very painful for some of the people I worked with.
Like I did a deep dabble in trying to create websites just purely with XML and XMLT at the time, which was novel, but it turned out did not stay around forever.
And so I love these kind of tooling bits.
And I think through that, on the PHP side, we eventually looked for, we had a big subversion server.
I got involved via...
Like people at Mayflower got involved into PHP community, worked on PHP stuff, and got part of the community.
And as part of that, they looked for a new version control system to replace subversion in the long run.
And so people brought up Git.
And then I looked into Git, and then I looked at FoundMitKurial, which was at the time already developed by a person now called Olivia Mackell.
And they started this exactly at the same week as Linus Torvald started Git.
but it was written in Python.
It had some cool extensibility bits.
And that's how I got engaged there.
I'm like, oh, this is a really cool community, way easier to write than writing C.
The people were really friendly.
And I got very quickly very engaged there because I was able to build a lot of things there myself.
So I started just doing a lot of open source things and did around 16, 17, 18, a lot of this engagement around like...
the Sversion Control System because I found them deeply, deeply fascinating of something so center to how we do things and somewhat magical.
And if you really think about it later on from a computer science perspective, I think I had an intuition.
that these are actually fairly complicated systems that have a lot of ingenuity around data structures and other bits to it.
And that kind of draw me into this.
It's like beginning to really go into systems programming.
And I developed a bunch of the key extensions for Mercurial that later became part of the core Mercurial offering and became part of that community.
But a part also was that that community was just nicer and more open.
And I think that's a big part to draw in young people and get people started in open sources, just to be a very welcoming community.
And the McCurrell community was that, which I did not find at the Git community, for example.
And in the PHP community?
I guess different.
On the PHP community, I got lucky that, again, the people at Mayflower, Johann Peter Hartmann, others, they were exceptionally amazing mentors and helped me guide through this.
And maybe what I didn't get from the PHP community, I got from them by engaging with the PHP community, if that makes sense.
Yeah, that absolutely makes sense.
I also know Johann for quite a while.
And when you mentioned XSLT, The term XSLT directly connects to Johan for whatever reason.
I don't know that it wasn't for me back in the days and he was so obsessed with it.
He likes to play around with things, which probably reflects on me when you were a young kid growing up about people that are very, very smart like Johan and see what they do.
So I think we have a similar approach to just dabbling in software.
But you personally, I would say, education-wise and career-wise kind of skyrocketed, I'd say.
You studied at TUO Munich, and I think Meta, I don't know if you directly went to Meta, but it kind of...
I went directly to Meta.
But again, this came through the Mikro community.
A lot of these things are put yourself into the right position, but then be a little bit lucky.
So I did...
I was working in the Mercurial community, and the Mercurial community comes together roughly every six months at like, you know, get together, work on Mercurial for a week.
And we went to Copenhagen to work on this together.
And at the time, Meta was really feeling the problems of growing their company really, really big in terms of engineering power.
And they were...
made a decision very much in the spirit of Google to basically move to a single repository inside the company and at that they will run into scaling issues with existing control system.
And so they realized that they need to invest into its own version control system.
And we can talk about like why It's just ever interesting.
There's a lot of reasons.
It sounds crazy from the perspective of an outside company, but it's usually a really good idea for, and a smart idea for companies all that size of Facebook to do these things.
And so they were recruiting quite actively from the Mercurial community because they were leaning into Mercurial as a very mendable open source project.
I mentioned there that I'm, you know, leaving, done with the university, I'm going to leave.
And then someone was like, hey, why don't you go apply for Facebook?
And I never considered it before.
So I applied, got in, got onto the source control system team there.
And yeah, I moved to Vancouver directly.
First a year to Vancouver and into the Bay Area directly after finishing the university.
So it's quite nice in that regard.
I got lucky there, to be fair.
Otherwise, it would have been like probably continued somewhere in Germany at a small company somewhere.
What are your biggest learnings from the Meta time?
Could you articulate that?
Yeah, I think it's an interesting one.
There's a few things.
There's a bit of Americanism, I think, that I think I've learned.
Americans, and then there's specific things to hypergrowing and companies like Meta.
culture of optimism and being technophile.
So really taking technology as a means to a better life and really living that.
I mean, I think that helps a lot.
Like if you really go out every day and say, like, I can change.
First of all, I can change the world, which I think is a very American perspective.
And it's true, you can.
Like a person can change the world.
And change the world and I can, and it'll be great.
And I will do something awesome and everybody will be better off.
And I think having that self-confidence and looking at the positive sides first rather than what can go wrong, which I feel is a more continental European perspective, I think is very, very helpful.
I think it helps a great deal in making big changes.
And so I think that's a big part of that, I figured out.
The second part is, and I think that's more interesting, at the time, it was the time where everybody talks about agile, people talk about processes.
In continental Europe and Germany where I work, I felt there was an obsession with processes.
And I think one of the biggest shocks for me is that there were no processes at Facebook.
There was no prescribed system at all anywhere.
The only prescribed system you had to do was like, use our internal software, basically, and, you know, put your performance reviews into the performance review tool.
But that's, and don't, you know.
certain amount of like, so like allowed software, but nobody told you, do you have to do Scrum?
Do you have to not do Scrum?
These type of things did not exist.
And it turned out if you give people the right incentive structure, if you hire highly talented and super driven people, which, and pay them really, really well, you actually need very little process.
And because of the lack of process, you'll be exceptionally flexible and agile because people just talk to each other and just.
make things work.
And that works surprisingly well.
And I was very surprised by this, by this lack of like, oh, you don't need to have daily, so you don't need to have a sprint planning or something like that.
And you just do.
I think that was refreshing and quite unique in how meta worked.
But was there still some issue tracking system around?
There were issue tracking systems.
Of course, there's issue tracking systems and you have these.
But the processes around them are somewhat loose defined.
And I think that's the interesting part.
You're not forced into needless.
There's basics like issue trackers, incident trackers, these type of things for the basic processes.
And some things that are like that where you had lessons learned, there are a bit more process heavy.
But again, you're not prescribing being agile.
And people self-select into the right model for the team and the context that they're in.
that works surprisingly well.
The second part is that there's a much bigger focus on managers being people managers rather than technical managers and supporting the people around them in doing their best and basically just there to remove roadblocks.
And I think that was another really interesting aspect.
Yeah, I think those things are really...
And then the last bit is there, you know, in the Bay Area in particular, but it's a cultural thing.
You have a culture of you work as your life.
The campuses of Facebook and others are optimized to keep you there.
You get breakfast there, you get lunch there, you get dinner there, everything for free.
You can stay there 12 hours.
You do your work out there.
Everything is fine, right?
You get there in the morning, you leave there very late in the evening and basically sleep.
The only thing they don't offer is beds.
Everything else basically can move your life to the campus.
And so there's a much stronger just work culture and you will find way more people on the weekends there and just cranking away.
How does that connect to family life?
Later on, I think people that are older, like me now, they make up their lack of time with this experience.
But the reality is the Silicon Valley is a young kids thing.
People drop out as they're becoming 40, 50 families.
The good part in the Valley is you make enough money, hopefully, on the way, right?
That's the bet you're doing in Silicon Valley.
You make enough money.
These positions at Facebook...
And the stock that comes with it are exceptionally well paid.
And by the end of it, you can retire or change or do something more chill.
But the reality is, yes, these companies tend to be young.
You will find 50-year-olds, but there will be VPs and senior executives.
And on the engineering side, you will find much, much fewer of them.
They will exist.
And they're very senior, but it's clearly not the same ratio.
I wonder if there's one company that attracts the older 10x people that still want to...
want to do it, right?
I mean, these people still do, and that's the same with Anthropik and OpenIA.
They still attract these people, right?
Like, if you have some of the best engineers, and we can talk about this learning at Anthropik, like Anthropik originally, 2024, hired mostly young people by accident for the most part, just by looking for junior people and hoping that AI helps them enough to be strong.
And then they had a series of all their big successes in 2024, be it Cloud Code, be it MCP, they were all done by senior people in their mid to late 30s.
And that's when it clicked for them, okay, we need to go back to hire more senior people.
And so you now have a way bigger influx of senior people come in.
And that usually correlates with age.
And the junior engineer still is not dead, I guess, right?
I think in many companies that was kind of felt like that.
I think.
But I think the narrative is also changing again.
It's a hard one.
I don't think it's dead.
I think there's a lot of opportunity because, again, what people might not have an experience they can make up in enthusiasm, in just availability and time and in crazy ideas, in not having seen the ideas.
If you're more experienced, you have a tendency to be like, Oh, I've seen this five times.
This is going to be all your problems with this.
And a young person might not have this and they might jump into something that will be hard, but they don't know it's hard.
And by just going getting started, they will push through the hard part eventually and make things work that otherwise, that maybe an experienced person would have said, oh God, it's so difficult.
Let's not do it in the first place.
And so I think there's a lot of benefits and you can, as a junior developer, you can do a lot of work.
But I think the focus should be, has shifted a little bit towards focusing on being, having high agency over learning a craft.
As I think 20 years ago, you might have seen a junior developer more as a person who learns a craft in engineering.
I think today it's more about learning behavioral patterns for how to be high agency and how to resolve the social dynamics inside companies and how do you navigate complex requirements rather than like...
how good is your code?
Yeah, I mean, that fits into time, right?
And how does, in contrast, how does Antrofic look like internally?
As far as you are able to talk about that, right?
What is different there?
Do you have processes again?
How different are you?
I think it's even looser than Facebook was.
So I think it's even this to the extreme.
So there's a difference there that there is...
So the company has a very similar approach of like you hire exceptionally smart people with high agency.
From the beginning, you select for people with high agency.
And you are focusing a lot on mission-drivenness, which is something very typical for Silicon Valley.
companies is that you take the company as a means to a greater good and the company is a vehicle to do so.
And there's a clear mission alignment within Anthropic around understanding that this technology we're building is exceptionally transformative.
And at the same time, you need to do it safely.
And I think that's very, very important for us.
And it's very important for basically everybody who comes in.
And so you do this, and then at the same time, you have very little processes.
You give them software, you give them the model for sure, and you rely on the teams figuring out the process and the workshops for themselves.
And you have very lightweight alignment, like things like, I know, like some very lightweight OKR planning every six months or something along the lines.
The reality is the field is moving so fast that The more time you put into these processes, the harder it...
The more time you lose, and by the time you're done with the process, you're often...
You're already often outdated because everything has moved on so quickly.
So you just...
focus for real high agency, quick turnaround.
And you're relying increasingly more on the model to just like grab the information that used to be like processes and companies used to be a lot about organizing information and information hierarchies.
And a lot of that is gone and much flatter now because you just can have to ask the model and the model just looks, you know, through Slack and Google Docs quite happily for the next two hours and just gives you the answer.
So...
Things have changed.
So I think it's an extreme form of the same agility with a much higher agency and a much, interestingly, a much higher ratio of output and performance per person because of the model.
control the ultimate outcome?
I mean, so there's two things, right?
There's the, how do you organize the people?
There, there's very little process.
How do you organize, for example, model development and like make sure safety is in place?
There will be a lot of processes there, right?
There will be things where you need to have checklists, where you need to have process of like, okay, we need to red team this, we need to check, make all the safety standards that we have set for ourselves, the policy.
people are involved, everybody's involved in like the model.
That is a very strict process, like the release process of a model and the development process of a model.
But the organizational bit, like how does the organization handle itself?
Like how do the teams handle themselves?
That is very loose for the sake of like, of just being able to adapt very quickly.
And you rely on the senior, the engineer, like it'll rely on just being, having smart high agency people that they will spot, that there will be a problem.
and they will solve it.
They will not sit in the corner and just happily tag away.
There's also another aspect that all the all companies have.
So first of all, you only go to Anthropic because you want to work hard, you care about the mission, and you want to change the world.
There's a selection bias here already and people who will go a long way and sit there on a Saturday if needed and go and sort out a bunch of emails to make sure we're all aligned and figure it out and pick up these things.
There's a second aspect to that that Silicon Valley companies are very good at.
selecting, at encouraging people via performance management, via incentives.
They have really figured out how to keep people high agency, right?
Like if you are sitting in your corner, tugging away a thing and ignoring the problems, well, you're not going to stay in the company very long, quite simply.
Because the company can quite literally just...
There's enough high agency people waiting at the door.
I can imagine.
Yeah, I mean, we saw Entropic hiring some prominent ones, right?
And if you think about this, like Tom Bloomsfield, who created Monzo, Big Bang, a lot of founders.
Why?
Because founders are the fundamental, like they are one of the most high agency people.
They're the ones who are like, everything is my problem.
I'm just going to go and solve it.
right?
Because nobody else is going to help me, right?
There's no company I can, there's I in the company, right?
And so these are great people and you will find a lot of that ethos and a lot of that mechanic across basically everyone at Anthropic, even if they came from bigger companies.
Understood.
But today we're also here to talk about harnesses, your personal setup.
how you actually work day-to-day when you code.
I guess you code a lot.
I guess you use Cloud Code a lot.
And we also want to understand how does that weave into MCP, CLI, and how do you personally think the most productive way is?
And the question, should every CTO build their own harness?
Should every engineer build their own harness?
So should every engineer know how to build agents these days and really like relearn like to that level?
And are we ultimately, will software factories that like figure out what to build themselves without human interaction really be reality from your perspective?
I don't know how deep you want to go, like just say, hey, this is the red flag.
Where should we start?
Let's maybe start with your setup.
My setup, this is an interesting one.
I think when we had originally the conversation, the setup was different than it's now.
So things have changed quite a lot, I think, in the last six, seven months in that my setup has shifted away from a lot of local cloud code.
So I would have local cloud code.
I have a...
Not a large set, but a small set of two, three, four, five skills that I really care about that I'm using.
Which ones?
Yeah, those are the customized.
Those are customized.
So I take basically Cloud Code Harness and customize it.
And we can talk about this as my work setup.
The private setup looks slightly different, but the work setup looks, of course, very Cloud Code-centric.
A few skills.
One of the most important skills is I have a skill that...
takes my writing style into account.
It's called My Voice.
And so it's about like, you know, here's some examples how I write.
Here are things you need to avoid.
Do not use EM dashes.
Avoid certain phrases that give away that you are a model, which I just, you know, that sounds overly enthusiastic or something like that.
These things I really honed out.
That's, I think, a big thing for me.
There are review skills that go like, hey, launch these five sub-agents and make one the architectural reviewer, make one the code reviewer, make one the Anvazero reviewer.
That's usually a skill that I'm quite often relying on.
So it's very simple things that most people already have.
There's one to go and read me, my key.
communication channels, like my Slack, my linear, these type of things.
And then, you know, and figure out like what are the most important channels for me?
What are the most important people to focus on that?
So those are really the three main things.
These are customizations that are mostly around personalization around my voice, my communication channels, and then a little bit of the harnesses around code review.
And again, it highly depends on your work setup and what you do.
Like if you were to be a CTO at the company, you would go like, I don't know, these are my external contacts that are the most important to me.
These are the main customers that are the most important to me.
This is here.
Here is the current vision document for the next six months or whatever it might be, or this is the product we're trying to accomplish.
So a lot of it is customization via skills.
And then a lot of it is like, a good part of that is in a combination of like CLI tools and MCP servers in the back.
Like the, you know, it's not, it's a handful, but it's like the important ones, like a linear MCP connector.
The Slack MCP connector is probably the most important one of them all.
And that's pretty much it.
Like it's like communication connectivity, like connectivity to all the bits that matter to me.
And I've always been a very vanilla kind of guy.
And the guy who uses Vim, vanilla, without much customization.
But those things are really the key pieces.
But again, it has changed in the last six months because what we have found is that we have released this now as an external product called CloudTag, which is...
Claude really has its own identity, its own access rights as part of your Slack channel.
And you just go and message Claude and say, hey, can you look here?
Can you look there?
And so a lot of my workflows nowadays are, hey Claude, can you look into this thing, review it?
figure out what you feel about it.
How do you make an address or review on this?
And then come back to me and or, hey, can you do a research here into this?
Or, hey, I need to change this over here, just implement this new feature over there, go and do it and come back when you have a review.
And so a lot of my interaction moved away from Cloud Code Sessions to like threads and Slack where I interact with Cloud and Cloud does the thing for me.
The magic thing about that is that if you interact publicly in channels, you also teach your colleagues on what you think and what you do.
There's a concept.
And they can jump in.
They can jump in.
There's this concept called, I think, River, coming from Toby Lipke, the CEO of Shopify, which is exactly that, right?
So I think they also built something internally like that.
What I kind of...
I really love this at first, and I think a lot about it.
And the question mark I have, like, does this fit into organizations where you have different contexts, which not purely around engineering, but also around marketing, etc.
And is there some way to also tie the tools in that people typically use?
So if you have a marketing team, uses Notion?
Does that work together with it?
I guess yes, right?
The thing with something like CloudTag is there's two things.
Basically, an IT admin creates a Cloud instance and says, this Cloud instance has access to all of this.
Now you have interesting compartmentalization problems.
There's a lot of very, very smart, complicated access rights things that we allow in the product.
This is Probably one of the biggest problems in the industry at the moment is access rights and these type of things for agents.
But there's a lot there so that you can connect like, oh, this is the engineering instance of Claude and this is what they can do in this channel where the engineers are and this is what they can do in this other channel where the marketing people are.
I mean, you give them different access rights or I don't know, the finance people clearly have a different access rights than the engineers because the finance people are allowed to see things that the engineers are not.
You need to set it up that way.
And it gives you a bit more compartmentalization.
But when it's set up, it works for everyone the same way.
And I think that's the sweetest part.
You don't have to create your own setup.
You just jump into a channel and you're ready to go.
But it's usually around channel permissions at the end of the day.
For us internally, we're very flat in hierarchies.
There's compartmentalization in parts of research for good reasons.
In general, there's very little compartmentalization and that helps quite a bit with the use of these things.
But yeah, in the end of the day, there's a lot of access to ways to do this.
You would just have a cloud that goes like in the marketing channels.
It has a different access, right?
It would connect to Notion.
It would connect to your Google Spreadsheets.
It would connect to your CRM systems.
Most of them, in the end of the day, have some form of connections, either via APIs or via MCP servers.
And both of that would work, yeah.
And the context itself is kind of proprietary in the background, or can this be dumped into a Git repository or something?
The context, no, how Claude generates its context and so on, that would be proprietary.
Of course, you can write the output of it to a Git repository and whatnot.
But as always, these are proprietary, not necessarily for the reason of...
making it proprietary, but for the reason of we're doing things like compaction, smart compaction, running models over it, these type of things that can be useful for people.
So for example, in another product we do, in our custom managed agents or cloud managed agents where you can create agents on the fly, we have a technique called dreaming where on a day-to-day basis we are taking all...
the transcripts and basically infer new facts about it.
And that's like, these things are sensitive to evals, these things are sensitive to how the data is stored, these things are sensitive to model selection and these type of bits.
And so that's why most of that is just like proprietary pipeline.
A guy just told me about a tool called G-Brain for Hermes Agent, I think.
He's using that in connection where it dreams every night and kind of derives stuff from all the other transactions that it lives through the day.
So a lot of these ideas and things will exist in the open source and you can build this.
The only difference is, of course, if you build it, it's like using Linux versus using Apple.
One is an integrated system where there's clearly The teams have talked to each other, have done evals, that this all works perfectly nice together.
And on the other one, you're on your own, right?
They probably work similar, but maybe not quite as good.
Okay, okay, understood.
So that means that your personal harness, let's say, is very simple.
And there's also no...
magic software factory involved in your day-to-day as far as I understand it?
Less so than you would think.
Yeah, I do.
On my private setup, I'm currently using Herder.
I'm not sure if you heard about it.
It's like a terminal emulator thing made for agents.
So it keeps your agents running and you can select them very easily.
And it's a bit of like an agent management thing for the...
for the command line.
So I'm using that.
And I have two or three instances of Cloud Code running around there over things I wanted to do, like be it my Kubernetes setup, be it my...
be it my software, like I just ported a workout software that generates me every week a plan of what I'm supposed to do in the gym.
And I ported that away from a website to an iOS app and let basically Claude do this all by itself.
What I do, so the way I do this is I have two or three of these agents running.
Two or three would be Claude agents.
I would have one or two.
other harnesses from sometimes from other model providers just to get an understanding of what they're capable of.
Some of them are very good at at Treseri reviews.
I use beyond Cloud Code, I use a harness called Pi, which is very, very good and self-extensible and very, very fun to work with.
And I let them run.
I let these guys run.
I started...
I was more obsessed with a more separate layer, you know, fun, little, you know, crazy setup.
But the thing is, over the last year, there's two things that happened for me.
First of all, Claude Code supported this still-called UltraThink, which is just like generating dynamic workflows.
So Claude will like basically write a bunch of code and then spawn 25 agents and then get them all together and do stuff.
That has replaced most of my orchestration bits for my personal setup.
And then Cloud Code now can talk to each other.
So instead of me having to coordinate between different harnesses, the harness itself coordinates itself.
And so I tend to go back to Cloud Code again as a private setup.
When it comes to running more in the cloud, there's something that I haven't played around much, but I find very interesting called Agent Substrate from Google.
which is like a Kubernetes-based thing that does a lot of the hard problems about agents for suspending them, resuming them, these type of things.
Workable, that seems to be a really fun thing I would want to try in a more production server setting bits.
And if you had, as of today, you had some sort of a framework desktop at home or something like that where you can run a local setup, maybe some local models, not necessarily.
what would you run on it?
Would it be Hurt?
So Hurtr is just running multiple cloud code instances for me.
I run every now and then my models, just run an olama on it and whatnot.
But it turned out that...
But this is where maybe my bias as an engineer at Ananthropic comes through.
I don't trust their alignment necessarily.
So I don't trust that if I ask a model certain things about political events that the code afterwards is fully secure, for example, I don't trust the output at all times.
Because I have very easy access to Cloud, I think that it's still by far the strongest model.
And I wouldn't want...
Why would I settle?
with something else.
The cost part is for me less of a problem.
I'd say cost is not a problem for most of the folks out there right now.
It's, I think, for many also experimentation, right?
Like, how does the local future look like, etc.
And there's a lot of debates around this.
But I think right now it's just like...
very comfortable to boot up Claude and just follow that path.
And I would run something like VLLM, just run some inference stack.
But there's a lot of cool things, the remote bits.
You know what I like?
I have my laptop, like, put it into the cloud, like, take this project, put it into the cloud, and then just let it run there.
And I just go on a walk and I continue talking to Claude.
And competitors offer similar things, but, like, these are very, these infrastructure parts are hard to do, actually.
And you can do it in open source, and you can find people doing it for you.
But it's hard.
And I...
that's where my world is going is away from the local development and more to the remote slash Slack and these type of things.
Yeah, I mean, the Slack setup is like the ultimate remote thing.
If you needed something like somehow in between, I mean, I often leave my laptop running and then start...
Oh yeah, I always leave my laptop running.
...clode remote.
And I wonder if there's one setup where I could just like...
which I could just drop on a local computer to avoid using my laptop at all to run Claude and to have all my context in there.
Yeah, people I do know have a server rack at home with a 5090 in it or a bunch of old A6000s or so.
And then they just run local models against us and you can probably get to a similar experience if you combine the right open source project.
The problem with all of that is a lot of the infrastructure bits take a long time to mature.
I think that's learning from cloud and just general development pieces.
This is all accelerated, but it's still very young as an industry and very young as projects go.
Most of these projects are less than a year old.
And so it's a bit hard.
which is why I think a lot of them still look janky.
Like, I just keep my Mac running, which is what I do too.
Instead of having a sophisticated, oh, I have everything perfectly running in the cloud and nothing happens ever.
Everything is perfect.
My inference is always up.
But the moment you run your own inference, you have fun problems because it turns out GPUs are not as...
not as robust as CPUs are.
And so there's a lot of things that you suddenly have to care about that you did not have to care about.
But you can go to Open Router and other things and use that.
So there's a bunch of options to play around with it.
Yeah, I wouldn't talk about local inference necessarily, but just having the context somewhere and organizing that and not necessarily having to reboot it or compact it every once in a while.
Yeah, yeah, no, no, I agree, I agree.
There are lots of things that do more and more context selection pieces.
I think there's an aspect where people were obsessed with RAG initially, and RAG in terms of retrieval augmented generation.
And I think it's going to come back eventually, because I think the models are strong, the context windows are not growing significantly bigger.
And as we want to get more...
tasks done, you will have to get better in selection.
And so, you know, back to Toby.
Toby has like this...
QLM thing, which does some form of embedding over markdown files effectively, which is quite useful.
I used to play around with a lot of code embeddings and these type of bits that you can do.
So there's a lot you can still do.
The reality is I probably put all my contacts that I ever need into an Obsidian vault and have Claude read it and just stay simple.
Yeah, I have everything in Git right now, so mostly.
Perfect.
Yeah, that is good enough.
You know, whatever works.
It turns out files and folders are very, very good.
The models love some files and folders because it turns out the internet is full of it.
Yeah, absolutely.
But the key question is always how to transfer that and maybe that's the spin to the company harness that many companies try to build right now.
You have different contexts, right?
And you just, like I said, you can just use Cloud Tech.
Fine.
But just taking that problem, would you say in a normal company, then marketing could also, like abstracting it from Entrophic and proprietary sources, have multiple Git repositories to deal with that?
Or, I mean, that doesn't work with marketing people, right?
Right.
I think the...
So it highly depends what you're trying to do.
If there's an aspect where a generalized solution like claw tag or similar things like, you know, co-work and all these other options for people doing work stuff.
I think these general things go pretty far.
You are doing this like slide customization for your personality.
You do a slide customization for connectors.
That gets you like 80, 90% there.
And for people who are new to AI and dealing with this, it is probably the right 80, 20 solution of getting 80, 90% there.
Where I think custom agents and where customizations come in, if you want to really replace certain workflows with a common with a common repeatable thing where it looks more like automation, software automation than like a coworker.
And I think in a coworker scenario where you want someone to help you, an AI to help you and just be able to connect to your sources, again, a generalized agent harness.
is probably the right way to do it.
But if you want to have like an automated flow, a custom harness might be better because you might be better and able to select.
You might be better to use different models.
You might coordinate different models.
But in the end of the day, the underlying techniques for how to build a harness, they're quite simple and they have not changed much.
What the harness does give you, it gives you flexibility and makes some trade-offs for you.
But you then have the other trade-offs that you probably want to have evals and all these other things that people that try to sell you a generalized harness will have done by themselves, right?
So that's the trade-off.
Again, I would build my own – I, as a CTO of a company, I would build my own harness just to understand how they work.
I would probably not buy one.
I would probably not run my own custom harness somewhere.
Because you can take something like Pi, which is highly flexible, a very good, strong base harness, and just modify it away.
And it's probably the smarter choice.
But the harness writing is not hard.
It's not that hard.
It's give it a bunch of tools, give it a bunch of execution steps, and be a little bit smarter about context selection and go for it.
And it turned out the model does 99%, like 90% of the work is the model.
And some of the ingenuity of something like claw tag...
is distributed systems engineering of how multiple cloud and sensors can talk to each other and their smartness in that.
Again, you can do this yourself, but that then you will have to basically be a dedicated focus on a harness product that you build internally.
So you think that most of the harnesses that are actually being built right now are probably thrown away then?
I think people build the dedicated harnesses, like the Hermes people and so on, that do certain things very well.
I think that will always be the case and will push the state of the art.
I think if you are a random company and want to build a harness, it's probably more to understand the problem rather than that you will ride a particularly good harness.
I agree.
The other thing is what you cannot do and what we can do.
We can reinforce my law on our harness, right?
We can optimize the model towards our harness.
Nobody else can vary.
Most people cannot do it.
And even if you take an open source model and try to do it, it's a hard thing to do.
So it suddenly requires a significant step up in understanding and research that most people do not have available to them.
As a result, likely a lab's harness like OpenAI or Anthropic will probably outperform most other harnesses for quite a while.
Probably, yeah.
I mean, never underestimate open source and the power of open source.
Still, I find that fascinating how much open source is being released around this, and how much is popping up.
Which is awesome.
Again, like Pi, I think is a great success story.
What Mario has done over in Austria is absolutely fantastic.
I think OpenClaw is just another really amazing, like just the form factor has changed.
The underlying harness might not be the top end harness.
It was 90% there.
90% might be good enough if the idea around it is strong enough by itself.
And I find it very fascinating how much you can build with like just Claude, right?
And just telling it, If you want to build, for example, an agentic system that kind of has an on-prompt somewhere through Slack or so, how easy it is to build all that, even including voice, etc.
That's, to me, just fascinating and also worth trying, right?
Yeah.
And there's a new age of custom software that you can do.
Again, I built my own workout app.
I have a home inventory system that I, it was open source and I'm modifying it, but I probably just rebuilt my own one because it's so easy now.
Yeah.
A friend of mine has his own Chinese learning app and so on.
You can do a lot of these things.
Don't need Duolingo anymore.
Yeah, I thought about like Recipe recently, like their open recipe formats.
And I don't know, I have all those recipes marked on Instagram, which I never transcribe and I never use because it's just like...
sitting in that one tab and just building something for that.
Yeah.
Do it and tell us how it goes.
I will.
The key problem is then to introduce reliability, right?
And this is where I think there's still a reason in buying software somehow or buying maintenance.
I guess this will also change.
I mean, I don't know.
probably it will change throughout the next months and years.
But for me, this is always where it spins back to.
In a professional context, would I build my own, I don't know, time tracking tooling for the company to roll out?
Probably not, because my company has other problems to tackle, and this is not a core problem.
Depends a bit, right?
Depends on the size of the company.
A lot of the problems that SaaS suffer.
solves is like large-scale distributed software pieces.
If you look at something like a linear, which I think technology-wise is quite fascinating, the underlying problem is simple and has been done many, many times, but the way they've executed this is very, very good.
And a lot of it is like deep understanding of web technology, deep understanding of synchronization mechanisms, and deep understanding of backend distributed software.
And this is hard to replicate.
It's very easy for you to build...
your personalized time tracking system that runs on like a Postgres or an SQLite database, it's a much harder problem to run this for 20,000 people where you suddenly need like complicated charting and backup mechanisms and failovers and high availability and these type of pieces, which just require you to have experience.
So there is hope for software engineers, you're saying.
I think there's hope.
I think there's hope.
I think certain parts of software engineering, might get very difficult.
The same way, you know, if you think of, like, I think there's a lot of equivalence in history here.
If you think about what was important in architecture, there are forms of architecture in building a house in the 60s that don't exist anymore.
And the work of an architect has changed.
Certain specific functions, like technical drawing, don't exist anymore.
They are now CAD software, right?
So they have shifted, but the fundamental piece that there is someone who understands and experience in building a house, that has not changed.
And so I think it's a similar aspect.
Things will shift, right?
Like if you are...
If you're in a very specific role and have done a very specific thing only, you only know JavaScript and you only know the specific things about CSS and whatnot, maybe that's a much harder to defendable position than if you're a high agency generalist or a deep researcher in machine learning or in voice recognition or whatever it might be.
Those things are hard to do.
If you're like a strong distributed systems engineer, you think you will have a job for many, many, many more years.
So you think it's about specialization or ultimately about a good understanding of automation, system architecture, and system thinking?
It's both.
It's both, right?
There's two ways you can think about this, right?
The one is broadness.
Like if you are high agency and can adapt quickly, that if you were, if you used to be a technical drawer and you loved and you jumped into computers and learned how to do CAD software, you will be fine, right?
And in fact, you will be very fine because you will be one of the first ones who knew CAD.
And so I think there, and then you will see a lot of this, right?
Like if you used to be a calculator, like a human calculator and have shifted and went to programming instead.
These are great opportunities.
So in these shifts, there's also opportunity.
And that's about flexibility.
And then there's pieces where we might see it will take a long time until models are very good at it.
And if you're very specialized in that, then that can be quite good for you, right?
That could be, let's say...
I take a random thing.
I do not know if this is the case, but if you were to be a deep compiler person, deeply optimizing compilers in 25 years, or you are amazing file system kernel developers, those are things that might be very defendable by being very, very deep into it.
It's a bit hard to tell because a lot of these things are at the moment up for grabs and the model is getting better at these type of things.
But again, There are probably pieces to it.
Like I think distributed systems engineering is just hard to reason about, hard to get context about.
I think these are things that probably will move on.
There will be needed humans for quite a while.
Okay, let's not make this too much of a human versus machines thing.
But I just had to smile when you said the job of architects has changed because I just built a house.
I don't know.
I think the difference is, that when you build a house now, the architect is kind of smart using all those tools, right?
And you can zoom into every screw in your, if you build like a wooden house like I did, like you can zoom into every screw and you see it.
The only problem is that the reality then that is built is kind of different from the plan.
And that the folks on the construction side kind of are really messy and not all adopt this new technology.
While with AI, I feel that everyone on the construction side uses it now.
And this, I think, can maybe lead to a better future of software, hopefully.
And not just for software and humanity in general.
I think there's a lot of opportunity there, right?
Like we're seeing accelerations in science.
We're seeing acceleration in biology.
We're seeing acceleration in mathematics.
I think there's so much opportunity here.
It's very easy to focus on the negatives, but I think there's a lot of chance in getting faster in cancer research, getting faster in building software for these type of things.
There might be software for pieces, but nobody would have written software before, like small NGOs or things like that that are suddenly possible.
And I think that's actually quite cool.
So let's quickly talk a bit about MCP.
I mean, you invented it.
So we have to give it some spotlight, right?
What's your today's view on your invention?
I think it aged quite well.
I mean, there was like quite a debate in February or so or March.
that CLI wins over it, and then there's discussions about skills versus CLI versus MCP, which to me don't make a lot of sense.
What's your view today?
I think there's two things.
I think it's clear that one of the key pieces to a model is if you think about the model being the brain of an operation, it has its arms and legs and its way to reach into the world and having some form of standard around this, I think is universally good for everyone.
And I think the, so having something like MCP, being at the right moment, the right time to do this, I think I'm very glad it exists because I think there's an alternative world where a lot of these integrations will be proprietary.
And I think it's better for absolutely everyone.
if this is instead of a protocol.
You mean the Gemini world, for example?
Yeah, probably.
Yes, probably.
But I think that's very good.
I'm very happy that it had the impact it had.
and that it's used everywhere.
I'm very grateful that our competitors were very nice and just adopted it.
And we now work together on the protocol and I'm very, very happy.
But there's a uniqueness in having created an open source project where some of the biggest and fierce competitors in this industry get together and work together, and very much in the spirit of open source.
There has been always this lingering thing.
Part of it where I think there's misunderstanding of what a protocol does.
There's this typical thing that if you are growing very quickly, you're getting hyped, people will...
think you are the one and all solution.
And everybody who's been ever in software knows there is no one size fits all.
And so it was always clear that if people were like, oh, you just need MCP, that's wrong.
You don't need only MCP.
You need also MCP, but you also need CLIs.
And so I think there's a lack of nuance in the industry that has caused the overhype of it.
And then the, oh, you don't need MCP.
But the reality is, is enterprises in particular love centralized.
things that they can control via gateways in the middle, where the deployment is managed by the development team.
So a lot of the things that we have learned from web development and the server side, owning the software and the server side, is super, super useful.
And at the same time, if you are a person who runs a local harness for your local development, and you have a computer that this harness runs on, running CLIs is perfectly fine.
but MCP is great if you need to govern this whole thing, if you need to not have an execution environment because you're on the web platform or whatever.
And so I think they both will be needed.
They're both equally good and they're just for different use cases in the end of the day.
And so I'm very, very happy in which I'm in retrospective.
I'm very, very happy having built what is pro what is probably nowadays very, very hard is to build a common standard that everyone from the big labs would agree upon.
And so I think MCP is in a very unique position.
And I just think we're all better off for having it, to be honest, even though, you know, from a technical perspective, it has evolved and it might not be perfect.
You know, I've never claimed that it's technically the best work of my life, but it's certainly from a social and industry-wide impact, I think just a net positive for everyone.
Many companies, it can make sense to have some MCP registry where they basically register their standard tooling, everything they want to make accessible for their company.
Instead of potentially building their own harness, I mean, I don't know, long term, I think this kind of looks like the better investment.
I agree.
Most people, that's what I see.
People have their registries.
They combine it with skills usually.
to capture domain knowledge, then do the general connectivity into the company via the connectors or the MCP servers.
The MCP servers all go through a gateway so that every interaction with the MCP servers are logged, audited, recorded, their policies on it.
And you know the interaction patterns and you know what these things do and you can govern them nicely.
And then on the harness side, you know...
Again, this is where like harness engineering, there's a lot of little nuances that you can do now in these modern harnesses like cloud coding, codecs.
They all are very smart around managing the context when you have a lot of MCP servers.
And so a lot of the problems that like people had seven months, nine months with context boats, all of them are gone, but you need to use a modern harness.
So yeah, I think it's the better investment.
That's what we see most companies do.
They just focus on like...
What are the MCP servers I need to build?
What are the MCP servers I need to just pull in?
What are the skills I need to build?
What are the CSIs I need to deploy?
And what is the basic standard set that is good enough for 90% of the people?
And then the last 10% will find their optimization anyway.
So it is generally a good idea to, whenever you look at a vendor contract, check, does it support OAuth 2?
Does it at least have a REST API?
Does it have an MCP server built already, right?
Yeah.
Yeah, just like this agent connectivity bit, like the MCP is probably the most native way to do this at the moment.
Models are getting better at writing API stuff, of course.
There are interesting bits around authentication that get complicated, which I think where MCP really shines by having a standardized authentication pattern.
But effectively, yeah, that's what you're looking for.
You really look for agent connectivity through like programmatic interfaces and that might be either an API or...
preferably an MCP server or a C-Life in the lack of it.
But then you need to have a computer where it connects.
That's scary by itself, right?
Then you need sandboxes.
That's a whole different...
Okay, good luck.
I just had to smile because yesterday I just was experimenting with my home network, which runs on Unify, like for many other engineers as well.
Same.
I gave Claude now basically access to my whole house.
And I'm a smart home geek, so I wanted to be safe and wanted to be secure.
So I trust you a lot.
Thank you for that.
And I basically told it to now secure my Unify setup a bit.
And it built me a custom CLI tool for it because it said, yeah, I don't see any MCP server available.
I don't see it being here.
I don't find the...
the CLI tools that are available are necessary, maybe too complex, so I just built something on my own.
Which, yeah, aged.
Okay, it works.
Yeah, let's see how it survives.
Interesting, because I did the same, but I did find an MCP server that will access your unified network.
And I had my cloud optimize my AP, my access point.
the bands and the signals basically using that MCP server directly.
So I did the same what you did, but I did a VRD MCP server.
Yeah, you're maybe a few steps ahead of me.
I wanted to first secure the network itself and build a few VLANs, etc.
I had to do that too, which is great fun.
It's good that this is possible now.
It's funny.
And I actually laid a look at my lawnmower like, hey, Is it secure?
Like, which ports are open?
Like, what can you do?
Like, can you hack into it?
It's always like a good playground.
I recommend that also to everyone out there, like, to just have a playground somewhere, right?
Which really helps.
But yeah, most CTOs have that already.
I had it.
I had Cloud recently write custom software for my coffee machine by, like, looking at the Bluetooth thing and, like, basically speaking Bluetooth to the coffee machine now.
and then built a little embedded device that displays some… I bought some embedded device, an Arduino device, and now programmed it to display some information about the coffee machine, which is kind of fun.
Yeah, I'm just about to do the same.
What vendor do you have?
For the coffee machine?
Yeah, for the coffee machine.
I have an Arduino.
I have a Victoria Arduino.
What do you have?
Like a Lamar Zaka or what do you have?
No, I have an Ascaso, which is a Spanish vendor.
It also has a Bluetooth stack and some ESP32 chip inside.
And I'm just thinking about the same, but I didn't do it yet.
Yeah, it's great fun.
They can do it.
They can do it.
I can show you some tricks later, like how you can get...
get the model to be really good at this.
Okay, yeah.
To all the people out there with Chinese cars, that's also a very interesting playground.
But be careful with that.
I have not let the model yet to talk to my car.
That seems to be not a good idea.
It's not the best investment of time, I would also say.
So, thanks a lot.
Coming to my final outro question, or maybe like a few recommendations from your end, what really made you productive in the last weeks and months?
I mean, Claude Tag and looking at that and looking at that from a company perspective is obviously something to recommend, I'd say.
What else, if you can now, if you stand in front of all the learnings that you made in the last half year and you dream a bit on it, what would be other recommendations from your end?
I think there's one or two, I think, things.
It's like the main recommendation is to not over-focus on optimizing your setup.
I think this is a lesson learned for me over the years, be it like...
you know, people are optimizing their VIM setups and so on.
This is a very fast-moving technology.
These things constantly change, and you don't need to double around with everything.
But pick, like, one or two things you find useful, like this be Cloud Code, be it Cloud Tech, do that.
And just focus on using it quickly and optimizing, basically, for...
for as little downtime as possible so that you can just get stuff going.
I think one of the fundamental problems is like, I think you want to get to the point where waiting on the model is not the bottleneck, but either you reviewing or reading, these are more the bottleneck pieces, and just focus on prompting and basically basic things.
I think that's really my main recommendation.
If I was a technical person, leading a company, I would definitely find two or three people whose job is more to go out and try a lot of different things and just tell me what's the right thing.
But there will be an infinite amount of things at the moment and you just can't keep up.
And you just need to make your piece that you cannot keep up.
So just focus on a lane that you want to pick and it'll be good enough.
And I think that's a big, big...
part where people get confused or they're trying to find the optimal solution and nobody knows what that would be at the moment and just finding our solution is better and optimizing for using that in the most efficient way.
Like for me is a lot of the rhythm is like get up in the morning, reread all the evening, the night, the night agents come back, kick off a bunch of new set of things, answer some emails, come back, review a bunch of code, get it in, these type of things.
I think that's, yeah.
So I think finding that rhythm, I think is really, really important.
So focus and think more about your core problem than your setup, right?
Yeah, I think that's basically what it boils down to.
I also think that many people fall into that trap of thinking about software factories while they have a problem with product market fit and really tackling customer problems.
So I think more about customer problems is an advice I'd also share.
Yeah, I think that's a good point.
You're probably better off.
going calling your customer for a half an hour conversation of why they're not buying this stuff than trying to build a software factory, even though the latter one might be more fun.
No, I definitely agree.
That's a very good point.
So, as an outro, I still have a little surprise for you.
So, you are a co-author of Mercurial, and I heard that there's a little Easter egg that was left off and abandoned that you personally developed back in the days.
It is a shelf extension you built yourself.
And the story goes, if you run HQ shelf with a date that doesn't exist, your working copy doesn't just stash your change it.
It slips you back through time with them.
Uncommitted, no trace.
So we can now run it with like HQ shelf, let's say 2010.
That's I think the year when you started off at Mayflower.
And we can now observe young David for a while, like coding PHP, like thinking about core contributions, thinking about XSLT probably already.
And you now have the chance to whisper something into your younger self's ears.
What would it be?
What would it be?
That's a good question.
What would I whisper into my own?
Probably.
If I was at that time, there's two things I would either do.
I would either whisper to myself, it's like, look, don't be too hard on yourself and just sit down, look at the code.
These things happen all the time.
Everybody makes this mistake.
You're not dumber because of anybody else.
That would be one thing.
The other thing is just like, stop drinking beer, go back and do the work and just stop partying.
One of the two of them is probably the...
the answer.
But yeah, I think the main piece is like, yeah, don't be too hard on yourself and understand that everybody makes mistakes.
And the only constant there is how you approach the problem rather than that there will be a problem.
Because there will always be a problem.
You will always break something.
Like, you literally broke something yesterday.
Thanks a lot.
Very good learnings.
Really nice episode, David.
Hope to see you soon in real life, maybe somewhere.
Yeah.
The Munich area or London or whatever.
Have a great day and really looking forward.
Thank you so much.
And good luck for IPO and whatever follows there.
We shall see.
We shall see.
Thank you.
Take care.
Thank you for listening to the Arsolist podcast.
If you like this episode, share it with friends.
I'm sure they love it too.
Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available.
Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company.
Please send us suggestions to cto at alphalist.com.
Send me a message on LinkedIn or Twitter.
After all, the more knowledge we bring to CTOs, the more growth we see in tech.
Or, as we say on Alphalist, accumulated knowledge to accelerate growth.
See you in the next episode.