# Retrofitting AI Into High-Performance Products

**Podcast:** Chain of Thought | AI Agents, Infrastructure & Engineering
**Published:** 2026-05-22

## Transcript

What I know for a fact is that the one thing that is helping me all out is pattern detection.
At the end of the day, it's like a new set of problems, but the way to manage those problems are usually through people.
Harness your management skills.
Welcome back to Chain of Thought, everyone.
I'm your host, Conor Bronston.
My guest today is Luik Goussier.
Luik is the CTO of Superhuman Mail.
Many of you might be using it to send your emails.
And he started his career doing applied cryptography and security research in France's defense industry, including work on nuclear submarine systems, which I might have to ask him about if he's allowed to talk about it, because honestly, that sounds fascinating.
He previously was CTO of OpenTrust, which was acquired by DocuSign, ran engineering at Product Board, and now leads engineering org at Superhuman, which Grammarly acquired for around $825 million last July.
What I wanted to talk to Luik about is the architectural reality.
of retrofitting AI into a product that was already successful without it.
Superhuman built its reputation on speed, every interaction under 100 milliseconds, and quality.
Then LLMs showed up, and the team had to figure out how to bolt on AI features without breaking the things that made the product special in the first place.
Loic, welcome to Chain of Thought.
Where are you joining us from today?
I'm from San Francisco.
Thanks for having me, Connor.
It is absolutely my pleasure.
I'm excited to talk about what happens architecturally and organizationally when you retrofit AI into an already successful product, because it's a really fascinating discussion.
It's very relevant to a lot of engineers and product leaders today.
But before we dive in, I want to give thanks to our presenting sponsors, Galileo.
I believe, I may have said this last episode too, but I believe it's going to be the last episode that Galileo sponsors with us after their long-running commitment.
I'm very thankful to them for being the founding sponsor of the show.
You can check them out at Galileo.ai and they build evaluation tools that help teams ship reliable AI applications and were recently acquired by Cisco.
So congrats to them.
Luik, let's dive into the meat of our discussion.
Superhuman's entire brand promise is speed.
Every interaction under 100 milliseconds, as I said.
Then you now need to integrate LM features.
How have you solved this tension architecturally?
Did we?
I don't know if we did.
Let's be like, set the baseline.
No, but we're living in that constraint.
We are living with that DNA in us.
And here I'm sitting on the shoulders of the giants that built the company before me.
I joined Superhuman.
a year and a half ago, and a lot of work has been done on the architecture of the product to bring that speed.
And the speed is coming with some heavy architectural decisions.
100 milliseconds, you cannot rely on network for everything that you do, which means that everything needs to work offline by default, which means that the business logic should work on your desktop, should work on your phone.
So there's a lot of replication, and then you need to have all those asynchronous jobs too.
sync everything as soon as you're online so that it feels good.
The good piece is that email is asynchronous by design, so it's sort of like okay, but still, that was like a huge endeavor for the teams initially to build that architecture.
Like, think about search.
You're on the plane, you want to search your email, like, how do you make it work without a network?
It means that we need to have, like, the data closer to you on device so that you can do those.
searches.
So lots have been said and done on this architecture before and then AI and then AI and changing completely the way we think about things because those Android milliseconds, how do you make an LLM like the inference, how is it run like under Android milliseconds?
It doesn't work.
It doesn't work.
So we need to adapt.
We need to adapt our stance.
We need to understand that there are some limitations.
That doesn't mean that we should not work on making it faster.
A good example is like we just released our voice feature on mobile a couple of days ago, and we were not satisfied with the speed of the interaction because everyone feels fast when you use superhuman.
If the transcription of what you said takes time and then is sent to an LLM for like the voice and tone and all of that takes too much time, you won't use the feature.
And it will feel so differently than the rest of the product that you need to work on it.
So we had to make some changes.
We had to think about pre-caching part of the LLM call to the transcription, providing the context, I would say, for your voice and tone independently than your dictation, I would say, pieces, for example.
So instead of having one call with a huge context, we pre-caching.
I would say load the context as much as we can and boom, then we send just like a payload of the transcription.
That's one example of things that we have to do before launching a feature because just making it work is not enough for our users and for us.
I love this example.
It's really interesting and I'd love to understand a bit more about it.
Are you able to share what you're using under the hood for transcription and more about how that process works?
I think these kind of architectural details are fascinating when you consider how to approach product integration with Elements.
So that was one piece that is like the speech to text and like getting your intent and like the pure dictation.
What are you saying?
Which is surprisingly the easiest thing that like.
So many ways to do it.
You can even do it on device now with like some really good results.
So that's not really what is hard.
What is hard is to transform your dictation into something that makes sense.
And that, I would say, the outcome of it becomes like a well-written email.
We expect our users to say, oh, reply to Connor that, yes, I'm ready to come to this podcast and I would love to chat about him.
Not sure about X and Y.
Oh, no, in fact.
I'm sure about X and just like giving some slots about my availability.
This is the way you expect people to speak to their phone.
Right.
I probably don't have the whole thing written exactly in my head.
I'm going to edit as I talk.
Yeah, exactly.
So, and when you think about this, so there's one trying to understand like what has been dictated from that dictation, what is the intent?
And sometimes it's like less because you speak about something and then you're like, no, no, no, no.
In fact, not, not that.
And you can correct.
So you need to have like this.
intent being really well framed and that intent being transformed into a draft email and that draft email understand the context of the thread, understand the context of how you voice and tone with that specific person because maybe you're answering your mom, maybe you're answering your boss and the way you talk to your mom and the way you talk to your boss, different people, slightly, slightly.
So all of that needs to be like it's a set of small bricks but a lot of that can be pre- fetched, prepared for the LLM to be just waiting for the dictation.
So all of that is happening behind the scenes.
So we did a lot of caching, which sometimes has a cost because maybe you hit the voice button.
So we sent all the contacts already, but we're like, in fact, not.
I will write it for whatever reason.
So the impact for us is like, yeah, maybe more cost.
Maybe more cost, I would say, to build this feature.
But at the end of the day, the quality of the outcome is better than for our users.
I mean, it's a no-brainer.
So for us, it's a no-brainer.
Are you using a single model under the hood for this?
Or is it one model for transcription and another that's kind of doing the rewriting?
How do you have this set up?
So we have models that are dedicated to every single use cases.
So it's not like one to rule them all.
We usually do that initially to understand how the Fiki to your can work potentially.
So we always go with them.
one expensive model, like the best of the models, let's try if the feature can even work.
But that's part of the process of the development.
We, I would say, iterate with that.
Feels, I would say, trying to find how it feels.
And then we have different models, I would say, to do things.
So, yeah.
Pretty, pretty dedicated.
Technically, I think we have some, ranging from some fine-tuned models that are just one specific use case to some not so smart models, but like cheap, but they do one thing that is really good.
And then some stuff like the agentic framework, for example, that we're using, we're using like the latest version of Opus to, I would say, to do this.
So depending on the use case, and usually we start by expensive, the best, and then if the feature is successful, how can we optimize?
How can we drive the cost down?
A good example being, so we have this auto-label features.
Initial, so identifying if an email is an FYI, identifying if an email is a pitch, identifying if an email is from one of your partners, or if it's a newsletter, whatever.
Classification problem.
At first, let's use, at the time I think it was a 4.0 model, and doing the classification.
Expensive, because we run it on every single email that you have.
But then we start to understand what are the right labels that make sense, and for those 10, 12, labels that we know would be useful for our end users, then you can, I would say, fine-tune dedicated BERT models and maybe running an inference into like dedicated infrastructure that are just doing cheap inference at scale.
So this is usually our mental model.
Try with expensive, make it work, useful for the end users, try to make it efficient.
I like this approach where it's like, okay, we can use a frontier model, a closed source model to nail in the draft of the feature, let's get it demo ready, let's try it out.
And then, okay, how can we fine-tune, I presume, open model to then make this much more efficient for us cost-wise?
And it sounds like potentially from a caching and latency perspective as well.
Yeah, totally.
And yes, you mentioned open source models.
Yes.
At some point when our auto labels, like we knew which labels, it was just like a typical BERT classifier type of models.
Let's do it with an open model and fine-tune it a bit, put it on a cheap infrastructure, dedicated, so not the typical infrastructure-as-a-service providers or those LNM providers, but dedicated.
People are a bit cheaper to do the work, and it's good enough for those use cases.
But we always start with the most, not most expensive, that's the wrong way to put it, but the smartest models to get the best quality so that we can really try the feature.
And if it's working with very high quality, then we can start optimizing the cost.
How do we then engineer what the smart model has already done for us, essentially?
Yeah, exactly.
And my understanding is that you often use double dipping instructions where you repeat key guidelines in both the system prompt and final user message to ensure that context gets carried through.
Is that still accurate in how you're designing?
It's not still.
It was used a lot when we were using, especially the 4O models.
4O models, for whatever reason, reacted well with this approach.
The Bayes' assumption was that the weight, or how the model is passing your context to provide the answer, was overly weighting the beginning and the end of the message.
So everything that was in between was sort of like...
lower, what was it weighted?
So less meaningful for the LLMs.
But so if you wanted to kind of counterbalance that, you were just making this double context and double request.
And so everything that was in the middle becomes higher up and higher down.
And we were seeing better results.
But now it's a matter of where you put the instructions.
Sometimes we're putting the instructions at the end.
So there's some stuff like this that can help us.
bring better outcome.
But this repeating the message was surprisingly good for four models.
It doesn't work as much on newer models.
I love that you're iterating architecturally because I think it's easy if you're not careful to get stuck in a certain mindset of like, okay, this worked for us in this last model series, but...
The model development is moving so fast.
The available tools and techniques are moving so fast.
How are you staying up to date and driving this iteration to ensure your team is actually continually optimizing?
Interestingly, I don't know if we do well there, but we had a session today with our engineers and talking about the cognitive load and how this is freaking hard to stay up to date, to not feel like a fraud, to...
like have Twitter, sorry, X, like open all day and seeing like all those guys that are like not touching the code for like the last seven months.
And one of my engineers, like I put like hundreds of codes, like written my hand this morning.
How should I feel because of that guy?
So the session was all about this introspection and how no one knows.
No one knows.
This is a planning shift.
No one has the answer.
There are some companies that are talking better about it.
But I think that every single individual engineer is facing these moments of doubts.
So to answer your questions, pretty much all the team is always on Twitter.
We complained about it.
You don't know if half of it is true, but you're still detecting patterns.
You're trying to understand, ooh, that specific GitHub repo is making some noise, and more people are showing use cases of this.
ways to build tools and skills and all of that.
Oh, that setup seems to work like in this.
So we share ideas, we share stuff.
And we have an internal guild, like an AI guild, the same way you could expect to have like a front-end guild, a back-end guild.
We have an AI guild that is talking like on a bi-weekly basis about everything they learned, like their pitfalls and like things that were working, things that are...
that were not working, but that are working now with the new model and things like this.
But it's freaking hard.
That's freaking hard.
Like even, like for me, like I'm not in the code day to day and I'm supporting the organization.
This is hard.
And you see like example of companies, they move super fast and you're like, damn, do I move that fast?
How can I bring that sense of urgency to the team?
But they already have too much of that already.
So how can I reduce the cognitive load so that they can focus on things?
But they should work in parallel because that's the new standard.
What about my factory?
And all of that.
So surrounded by questions and trying to focus like one step at a time is probably the answer.
But for sure, maybe like to answer your question, we never take anything for granted.
Every two weeks or three weeks, there's a new thing that is coming that might change the way we build, that might change the way we implement a feature, that might change the provider that we're using, because even the providers are changing super fast.
Trying to cope in a world where you need to be nimble and ingesting information is crazy hard.
So I don't know.
I don't know if I'm doing anything well there.
Resumate so deeply with these emotions because I get to talk to incredible leaders like yourself on this show once a week.
And every time I'm going, oh, God, OK, am I am I doing this right?
Like, oh, wait, there's a new thing.
I haven't done that yet.
I got to think about it.
And then to your point, there's just this constant stream of information on the website formerly known as Twitter X.
And it is, I mean, half of it's BS totally.
But then there are incredible innovations happening.
There's amazing stuff being done.
I have a friend who just showed me his agent factory the other day and I'm seeing how he set it up and I'm going, oh God, like I'm so behind.
Like a month ago I was feeling really good and now I'm like, oh, I need to improve.
And it just, it feels constant and it's hard not to emotionally feel that.
But I do try to remind myself that we're all on this learning curve together and No one has that much more experience in the current model development.
Maybe they have a couple months more.
Maybe they have a year's more.
But things are changing so fast that if you lean in and you want to learn and you're excited about it, there is such an incredible opportunity.
And honestly, it's one of my favorite things about doing this show is to talk to folks like yourself and just have a conversation because I think it can be really kind of scary almost if you don't have those conversations.
Yeah, to double down on this, one thing that I love to do to have the balance is I'm deeply involved in the startup world and YC companies and all that.
And I try to, for one, try to invest from time to time.
But two, especially listening to those people that are funding companies because they are seeing something.
They have detected one pattern.
two patterns, three patterns, they are detecting something and they believe there's a space for them to be like the next anthropic or whatever.
And you see those people and age can range from like teenagers almost to like, I'd say, more like gray hair people like me, but they share the same threat.
They just don't care about what was existing before.
They don't live in legacy.
They just live in this new world because they are building from scratch and they build with that mindset in mind.
And this is highly refreshing.
It's creating a sense of urgency because every time I discuss with those people, I'm like, oh, damn, I'm so cooked as a leader.
They're moving so fast.
They're thinking like so differently and everything.
So I'm self-creating this sense of, as you said, I'm so behind.
I need to catch up.
I need to catch up.
I need to catch up.
But I balance that with talking with more people like me.
And this time I'm not talking about gray hair, but much more like, okay, you're...
a CTO leader, you know, like in a tech space, your company has a success or like a relative success.
And now you need to manage customers.
You need to manage, and I was saying, a code base.
You need to manage some SLAs.
You have some compliancy.
And so you're facing, and you have like an existing team.
And like, oh damn, it's not only two people anymore.
So like you cannot just do things the same way.
And discussing with those people that are facing the same problems that I face.
is somewhat reassuring.
Like, okay, I'm not the only one.
I'm not the only one trying to catch up here.
But having that balance, for one, those startuppers, like very wise seafounders, like they don't care, they're already there.
Like, okay, let me like try to piggyback.
Come, talk to my team.
Oh, I love your solution.
Maybe not for us today, but maybe it will be like in three months.
And this is also creating for my team a sense of what's happening on the market beside the semi like PS that's happening on X.
Those are real people building real stuff with some real use case that my team can be inspired off or at least understand that this is where this is going, which is so much better than just me talking and trying to be like the wise guy in the room.
Luik, I love that perspective because I think it is such a balance.
And I'll say, if you do find the next Anthropic, please call me.
I'm happy to co-invest with you.
You can just give me a call.
I'll send you my number after this session's over.
Let's refocus a bit on what you're doing with all that information.
You're driving a lot of insights both from people on the bleeding edge, folks who are trying to work through this at scaled orgs.
How have you adapted your team structures, if at all, to chase this new reality of software engineering?
I think we have a relatively standard organization.
We're pretty lean.
So I think that I have something like 13.
13 direct reports, both engineering and product.
PMs are reporting to me right now because we have a founder that is very product-centric.
So I'm not claiming that I'm anywhere close to a CPO, but I think that I'm a good operator and working with a product-focused founder that works.
So pretty lean organization, very pod-focused.
So AcuPod is led by a triad, PM, tech lead.
and designer.
So very, very typical.
I have a platform team that is supporting the overall organization.
My platform team is focusing on the core AI pieces.
When I say core AI, it's like, you know, the router, like open router type of internal implementation, like which LLM to use in what use case, how to flip from one LLM to the other LLM, how to plug your evals in the system, working on the evals infrastructure so that the feature teams that are not feature teams and they are like focused on the experience.
So like I have a team dedicated to the calendar experience.
I have a team dedicated to the mobile experience.
I have a team dedicated to the triage experience and a team dedicated to like a crafting email experience.
So each of those are like fairly autonomous, supported by a platform team that is working on the foundations of the AI PCs.
Like, hey, you have an idea of what you want to build?
You build it.
We support from like a...
API standpoint, like prompt management standpoint, versioning and all of that, EVAs associated to it, don't care about that.
You have like something there.
There's a golden pass.
But each team is fairly independent.
And on top, we have like a product-led growth organization that is helping.
So to answer your question, I think the best move that we've done was one, to keep ownership of those teams.
Like you own it.
This is like my EM on that word is a CTO.
You own your partners, you own your providers, you own the shit.
Same for the PMs.
I expect them to know the YC companies that are working on this domain.
Example being mobile.
You're working on mobile.
You need to know all the companies that are working on on-device models.
Maybe it's not ready for us, but once it will be, you better know which company to work with.
Maybe you have some POCs.
Maybe you have some incubation work.
Your job to do it.
So very pushing down at the team level.
this autonomy, so we call it like aligned autonomy.
We call it like anyone could call it like aligned autonomy.
So my job is to align the team and driving the autonomy this way.
And just to finish, sorry, Connor, I know I'm super verbose, but we have this guild, AI guild team that is like...
standardizing the way we use AI, working on the factory, identifying things that needs to change to be agentic first.
And all of that seems to work okay.
Do you find that your experience aligning, I'll call them human models, people, helps you when it comes to getting our agentic models up to speed on what we need from them?
I'm asking this somewhat jokingly, but I think it's...
Important to acknowledge that a lot of what you're doing here is structurally similar, organizationally similar to the work we need to do as engineers and architects to build great AI systems.
You're creating autonomous nodes within your organization that will act as second, third, fourth brains for you around specific topics.
You are spinning up sub-agents, so to speak.
And I just want to remind everyone listening who has experienced leadership or has thought through these topics that This knowledge is applicable across these disciplines.
And yes, there are clearly differences in how you manage a human and how you manage an AI.
But the documentation work you do, the enablement work you do can be very similar in some cases.
And it seems like you are taking the same iterative and I guess I would say specific approach in your product design where you're going, okay, you know.
I have identified the best way to do this or the easiest way to do this with a frontier model.
How do we then jump to what's on the bleeding edge?
How do we then break this down into its component parts?
And I'm curious to get your perspective.
Do you feel like your leadership experience over the years has informed these decisions or am I conflating two things?
No, no, no.
It's surprisingly thought-provoking, but not that I think about it.
There's this delegation framework that we always think about, which is like, depending on the seniority of the person, at first you ask to do X, then you explain why you need X and you ask them to do X because they're better at understanding the context and why this makes sense.
And then when the person gets more and more senior, you give them...
like an explanation of the context, but they might be able to understand, I would say, what type of solution they need to bring.
And the last, I would say, space of delegation is you just give them the problem and that they will figure it out.
And the same approach sort of like comes like when you think about it now, or you force me to think about it.
The same approach, I would say, works, but like backwards, interestingly, with models.
Because we start with the smartest model, and we can be just like dumb in the way that, hey, this is a problem.
Okay, the smart model will figure this out, we'll get some great output, we can build on top of it.
Great.
But this is freaking expensive.
How can we provide more context, more hardness in this dumber model to get the same outcome and come back to like the...
kind of like moving backward from like the cheapest model, but by providing way more harness and may work way more context about things.
This is an interesting point, Conor.
Thanks.
Thanks to Galileo for sponsoring this episode.
Their new 165-page comprehensive guide to mastering multi-agent systems is freely available on their website at Galileo.ai and provides you the lens you need.
to understand when multi-agent systems add value versus single agent approaches, how to design them efficiently, and how to build reliable systems that work in production.
Download it for free at the link in the show description to discover how to continuously improve your AI agents, identify and avoid common coordination pitfalls, master context engineering for agent collaboration, measure performance with multi-agent metrics, and much more.
And I actually think it's something that's evolved the last couple of years.
So anyone who's followed me for a while knows that I've talked about this a bit where like, I don't know, call it two years ago, I was like, uh, you know, LLMs are interns for you right now.
They're useful, but you have to really walk them through things.
And that's started to change.
And now there are times where an LLM is more like a senior engineer and who can say, okay, like describe the problem space.
Let me go figure it out.
Um, and even at times going beyond that.
So I think this is one of the biggest things that I've seen as a leap where I.
feel very comfortable now, even if I haven't given an extensive prompt saying, oh, I want to use auto mode or dangerous, let's get permissions or, you know, autonomous fully that just go do this, uh, depending on the model, obviously, but it is important to vary it because I mean, the research you talked about there about basically growing employees to be able to take a problem and solve it themselves.
That's the ideal employee you want to get to, but they are typically much more expensive because they know their worth in the marketplace.
And the same is true of a frontier model.
Uh, so How do you evaluate success on the model side?
Obviously, we have years of experience doing this for humans, whether or not we're good at it.
You know, we have modes for it, right?
And I think there is an opportunity for us to get really good also, though I would argue maybe we aren't yet, at evaluating both frontier and closed source and open source models using canonical queries.
I know this is something that you're doing at Superhuman.
What's your approach been?
trying to understand what we were trying to do.
So everyone was doing evals.
So we were doing evals.
And sort of like using both real data, synthetic data, and like input-output.
But pretty fast, we faced some issues because the field of possibilities was too big.
I will give you one example.
We work on a feature to auto-draft.
response to answer those questions that you may receive.
Maybe it's someone pitching you, maybe it's a friend of you that is asking for your availability next week.
Maybe it's like, I don't know, whatever that can be.
But when you think about it, the possibilities are tremendous.
So we try to think about, and that's the role of the PM, interestingly, we're discussing that.
Is it the role of QA?
Is it the role of engineers?
Is it the role of the PM?
I think it's the role of the PM to identify the dimensions.
of evals that you want to solve for.
So I will give you an example.
Finding your availability and responding to someone with your availability.
This is one specific dimension.
I need a bunch of like, I would say tests, like hundreds of tests, like of type of questions, different ways to ask for your availability, different ways to answer your availability with voice and tones and everything, and different type of availability that you have.
But that's only one dimension.
You can also receive questions about, like one query that we used that was fun was, how much time did you spend in Waymo last month?
It's a very, I would say, simple query.
It's a very simple question.
So it's very easy to understand the intent of the person that is asking that.
How much time?
And the answer is you're in your emails.
So you need to understand what are the emails that are received from Waymo.
and you receive a ton of emails, and Waymo is, like, sending me, sure, like, receipts, but they're also sending, like, marketing content and all of, like, survey content and whatever, like, things.
So you need to have this to be solved.
Then you need to understand, oh, he said last month.
And we know that LLMs are really bad with dates.
So, like, what is last month compared to today?
So there's some part of, like...
that you don't want to adapt to the LLM and you want to say, no, no, no, last month means this.
And you provide a date.
There's also the piece associated with finding a date, like the duration.
So you need to find a duration.
What is a duration?
The concept of a duration.
So there's a specific ontology associated to it.
And then you have the duration and then you do submission.
You need to summarize, like sum, all of those bills that you receive from Waymo to eventually answer your questions.
So you take one query.
And you understand that for 20 of those queries, for that specific query, you need to cover from an eval standpoint so many different dimensions that you didn't have before.
And it's not a matter of having like 10 times this or like hundreds of examples of this type of questions.
It's going back to these eigenvectors.
Like what are those dimensions that would be used by most of the queries?
And this is something that all the...
EVALS applications are not managing for you and we had to build on top of our own provider right now.
So we have an EVALS provider, but like all that level of abstraction, understanding what are those dimensions that you want to cover can be then reused by like for other features.
I don't know if I'm clear, but it was like significantly painful, but we are happy to understand to have this framework because for PMs, it's framing what they want to cover.
Like what is the definition of DOM?
What is quality?
Well, once you have those dimensions that you want to cover, all of a sudden it's simpler.
And because you focus on those eigenvectors and you don't have to focus on the full space.
I appreciate the explanation about your approach here.
And I love this example with Waymo because it does speak to a variety of tasks that have to be achieved to be successful.
And there's a clear right and wrong as well.
And I imagine that designing for this was an early decision you had to make when you came into Superhuman.
Because my understanding is that when you joined the company, The very first day, they had just kicked off a six-week sprint to launch the AI Inbox feature, and that completely changed the product roadmap and ultimately the company's trajectory.
How did you structure that sprint?
And then what did you learn from that experience that you've now applied into your approach over time?
The first thing is that that was the best and the worst onboarding experience that I've ever had.
It was the worst because I had no clue, like no time to ramp up, of course.
But I had to help and support a team that will have to deliver a significant project, which is not easy.
You want to at least take the time to understand what you're talking about.
But it was also the best experience because I had no choice but to be in the trenches with the team.
Acknowledge the fact that I don't know shit.
Pardon my French.
And I hope it's okay for YouTube.
But I didn't know anything.
And I had to build trust with those people.
And I don't have a lot of opportunities to do it.
So like from the get-go, it's like, guys, we're in this together.
This is the mandate.
This is the context.
This is the mission.
How can I help?
And the reaction from the team was just phenomenal.
And I think that me being direct and honest about what I can and can't do and just managing the expectations with the leadership, supporting when needed, making the call in terms of like...
move of people toward this project was key.
But yeah, like I heard about it, I think it was like June 30th and I started like June 2nd and I had a call from Raoul basically saying, Loic, we're changing the roadmap.
It will be wartime when you start.
Cool.
Sounds fun.
Sounds fun.
But at the end of the day, that was the best onboarding I could dream of because we were in this together.
And the team worked hard and rise to the challenge.
Hopefully I was helpful and useful.
And they were able to better test me in the first weeks to understand how I was reacting, how I was supporting, how I was managing up with Raul, the founder, how we were working together.
And after that project, I would say sweet and tears because it was like sweat, not sweet, sweat and tears.
But after it, there was like a level of pride of the achievement.
That basically started the year on a very high note and built a strong level of confidence in our capability to execute.
So it was really cool, actually.
It does sound like a very intense but exciting and valuable onboarding experience that I can imagine quite stressful.
And I'm sure one of the things you were fighting during this experience is something I heard you describe, I think on the Lazian Space podcast in December last year, where you drew this distinction between building tools versus agents and talked about fighting agent laziness.
And anyone who listened to our recent episode with Anoush El-Ngovin over at AMD, you'll know that he called agents quite stupid and lazy.
And I think this is something we've all experienced at times, despite how useful they are.
I'm not trying to kill them.
You have said, and we've heard people like Satya Nadella talk about the inbox as the ultimate AI agent experience for the future, but you're not building a single monolithic agent.
Can you unpack?
what this direction for the company means?
Wow, there's so much to be said around this.
The first thing about the, I do believe that email will become more and more important in this agentic world.
Just think about the move from Cloudflare, where they basically, I would say, build this email for agent so that email can discuss with each other.
It's clearly like the number one use case that open cloud or town or those like a very agentic, your personal agentic assistant are trying to solve for.
It's like this email piece because email is draining.
And this is what built the success of superhuman.
Email is so draining that people are willing to invest money and time to make it better.
So yes, this is probably where people expect the most.
In fact, it's also where people are the most fearful because it's very easy to look foolish.
If you totally delegate your inbox to an agent and you don't know what will basically be answered or you don't know how this will be maybe archived without you knowing and damn, you didn't reply to this super important email of yours.
It's both super important and super tricky.
So to some extent, this is...
something that needs to be dealt with high precaution, even if it's the first use case that you're thinking about.
I will give you one example, but it's look foolish is part of our QA pattern.
So something that makes a user look foolish is a P0 bug for us.
So it's a category of QA bugs that look foolish because we archive an email and they missed it.
And it was something that was important.
Paying school, for example.
Oh, shoot.
Or, yeah, school email that is basically saying you don't have daycare tomorrow.
We archive it.
You don't know about it.
Shoot, you forgot to pick up your kid at school.
Not only you know foolish.
That's like a worst case scenario, honestly.
No, but yeah.
But this is giving you like a little of how critical emails can be and how you cannot just be like.
too fast in doing things.
So that's why like you're building those, I would say, AI features takes time and you need to think about all those like dimensions that I was talking about to make sure that your features is, I would say, happening well.
And for example, we do not want to send emails in the name of our users because this is too risky.
We do not send.
We auto-draft.
It's here for you to just hit send, but we won't send an email for you.
For now.
For now.
Maybe one day.
Maybe one day, but like right now, our users are not ready to just let that go.
I understand that completely.
I have to admit that my personal email is under Gmail.
Please don't judge me.
And when I was building some tools for it, for honestly, like post-production of the podcast to build out different lists of, hey, here I need to follow up with the guests, you know, let's automatically draft some stuff for them.
When I did that, I explicitly set up an MCP server using the Google Workspace CLI, and I did not include the ability to send the email because I was like, I don't trust this.
I need to have to review this.
And yes, it's a bit of a headache, but continually I will find errors.
And is it very convenient to have this draft made for me?
And does it help me a lot with my workflow on the show and in other situations?
Absolutely.
But there is a high degree of importance to some of these emails, particularly ones from when it comes to like archiving your inbox or something like that, to your point around missing important emails.
I mean, I started to tense up just hearing you talk about like, oh God, I miss picking up my kid from school or I missed a notification.
Yeah, 100% understand.
And I appreciate the attention to detail here.
And one thing, sorry to rebound on what you said about agent laziness, but there's the agent laziness, but the other side of the spectrum is the agent agency.
And if you allow, by design, some features like data deletion, or sending an email, or managing your money, or whatever, whatever the number of harness that you put around the agent, it's probabilistic.
It's probabilistic.
So there's one way or the other that it will basically mess up with your money, mess up with your emails at some point.
And we had like an example over the weekend where like some harness was there to avoid the agent to do some, I would say, important things with money.
And like, damn, we had the harness.
Yes, but like probabilistic.
And right now, if you want to have like a real true gate to protect things, you don't expose them to agent.
That's the only way.
So very much aligned with you.
And the agent laziness was a problem for us initially because agents were hesitating to do stuff because the model providers were like very, very like asking always the user, should I do it?
Should I do it?
Should I do it?
Should I do it?
If you see Cloud Code, it has been designed to always ask you the same questions and you need to really change the configuration to say, no, no, no, don't ask me this.
I'm good.
I'm good.
So I think that even the model providers are becoming less.
Like optimizing for laziness, because laziness means you decide and you can override.
Because if you have too much agency, you cannot override agency.
It's done.
It's over.
And it's interesting.
I made some mistakes about this agency, like in my own Obsidian setup and Cloud Code in my second brain.
I have scars now.
And I don't want my users to face the same.
Yeah, it's...
It's really interesting you bring that up.
I have moved to keeping all of my notes, all my personal contacts in a Git repo because I don't trust the agent not to screw it up.
I want to be able to restore and I want to have clear catalog of what's happened.
And it creates some unbuildiness.
But yeah, similarly, I've had some scars there.
I'm like, okay, everything has to live in Git if it matters to me.
Yeah.
And when you see that even like PRs can be reverted, even without you knowing, like when you see the latest like Git brands, like messing up with like data correctness, this is scary.
It's like if they cannot do it, I mean, it's tough.
So yeah.
This conversation is not meant to scare y'all.
It is a very exciting time, but there are risks.
Like we have to consider them.
And I appreciate the attention to detail you're providing here too.
Yeah, and I think that to go fast and be efficient, you need to understand the risk and the limits.
The more you understand the risk and the limits, the faster you are, I believe.
So that's why also we need our people to understand what can and can be done.
So that's your job.
You just don't guess.
You just don't guess.
Especially when you manipulate people's emails.
How have you changed your hiring practices to match this current era?
That's very interesting.
So for one, superhuman male hire product engineers compared to superhuman corp, Grammarly and Coda, we are optimizing for software engineers.
So we have a DNA in that sub business unit, if you will, that is very user-centric.
So we have already like a hiring process that was different.
Like a great software engineer was not enough.
We needed to see someone that has an appetite for design, even if you're a backend engineer.
Like you're designing a backend system.
If you're not asking about the user, the experience, and how this can be reflected in their own experience, you're probably not an engineer for superhuman make.
So for one, we already had this very user-centric approach to things.
But now we're trying to understand how we can bring that in.
Because, yes, we need the fundamentals.
We need people to be able to debug.
We need to have engineers that understand what they're doing and talk in depth about, I would say, the work that they've been doing.
But how to test AI fluency is something that we are still figuring out.
I've seen that the town, especially, like they've implemented, like they just bring their GitHub repo.
And they said to the engineers coming in, you plug whatever you want in there.
And try to build this and help us go through your thought process.
They look at the way the person is prompting, the person is preparing the plans, the way the person is discovering the code itself to measure this AI frequency.
We are not doing that right now, but it's about to start probably like this quarter.
That being said, I can tell you how this is changing my own interview.
So I asked people where they are in the journey, not to understand if they are like...
using the latest tool, but how they change their approach, how open they are, how they tweak themselves without waiting for whoever the CTO is telling we need to use X, Y, or Z, how they are trying to self-correct, self-improve.
Some people are just happy with whatever the company will be providing.
And in this world, I think it's not enough.
You need people that will augment themselves because there's no way.
One size fits all and we'll be supporting all engineers.
That's great advice.
And it makes me wonder, what would you tell other leaders who are listening about what you think the future looks like for building an engineering org?
You mean the future in two weeks or in two years?
Let's try for like...
six months if we can.
That still weighs out.
I don't have a clue.
I don't have a clue.
What I know for a fact is that the one thing that is helping me all out is pattern detection.
At the end of the day, it's like a new set of problems, but the way to manage those problems are usually through people.
So at the end of the day, harness your management skills.
noble way to say it, like the real management piece, like how to deal with people, how to convey a vision to people, how to change behavior, how to, I would say, support people and detecting patterns.
I think this is the one thing.
So it's interesting to mention the fact that I was working in the defense industry and I cannot talk about everything that I've done, but, and nothing crazy, but one thing that helped me understand is that your knowledge can be I would say, put into different areas.
And one thing that I've done there can be applied to tech industry.
One thing that you've done in Coburn, with a team focusing on Coburn, can probably be applied with people working with agents.
At the end of the day, you're managing a set of people with different tools.
The tool is in the air changing?
Fine.
But as a leader, I would say, don't focus on the tool.
Focus on the core aspect of your job, which is helping people to find the right tool.
Well, Luik, you brought it up, so I have to ask, is there anything you can tell me about nuclear submarines that I don't know that you're allowed to talk about?
I think this is probably so bizarre, like the international context and all of that.
So I take everything that I said with a kind of sword.
But for one, this is probably the one piece that is able to bring peace because you never use it.
You hide it, but you are, I would say, fearful enough.
that are like, you're like frightening people so that they don't mess with you.
So I think it's a good tool for peace.
From an engineering standpoint, this is freaking crazy.
It's a nuclear power plant inside a tube that is like in the sea, like moving like this.
And engineers need to work for this.
So like sometimes it's like when you have some engineers with Strong Eagle working in tech, like, hey, there's some people that have been some crazy shit out there.
And sure, tech is fun.
Tech is very rewarding and everything.
But here we go.
Keep it for yourself.
So just the sheer amount of engineering that needs to happen to just have a nuclear submarine be safe for the 200 people that will be in it, that's mind-blowing.
Thank you for indulging my curiosity, Luik.
It's been a pleasure having you on the show.
Any closing thoughts for our audience?
Yeah, maybe one.
We're struggling as leaders.
You have access to mentors.
You have access to peer leaders and all of that.
You have access, maybe you're consuming content that is slightly different.
You have more experience.
You have gray hair, maybe not your team.
So I think that, yes, it's tough for us as leaders, but I think it's even tougher for our teams.
And we need to be conscious of that.
It's a great note to end it on.
And Luik, thank you again for coming on and sharing your insights.
I wish we had more time.
It's been a distinct pleasure.
I need to pick your brain more about the lessons you've learned building critical infrastructure for nuclear submarines, your experience with cryptography, and so much more about how you've managed acquisitions and are building teams today.
It's been great chatting with you and definitely recommend anyone who is looking to join a great engineering org that I suspect the week probably has a couple of roles open or will have them at some point.
So how do we, how do we.
What's the right website for folks who are interested in checking that out?
Superhuman.com slash career.
Bunch of roles opened there.
More than a P2B referral ping me with some context on LinkedIn.
And I shouldn't be a stranger.
I should be fine.
Amazing.
Well, Luik, thank you so much for coming on the show.
It's been great having you.
Thanks for having me.