GenAI In Asset Management – Learnings from the ground #1
GenAI In Asset Management – Learnings from the ground #1
Over the past few months, we have hit the ground running, focused on creating an AI-native asset management company from scratch. Given my background as an investor specialized in data/tech and having already co-founded a software company in the last decade, I had some general ideas about where to go and how it could unfold. The following article is a compilation of what we observed first-hand.
I do not think I am breaking down any revolutionary fact here, but I hope that the fact that we are neither working at a frontier lab nor a consultant trying to sell something gives it some value.
Software: build versus buy
As a general comment, we intend to be as lean as possible and have a cost-competitive structure, and most team members have some capability to build/prototype apps to some extent. Therefore, we would be mostly inclined to build according to our needs. Here is what happened.
- Software we are building:
o Verticalized software that does not exist in the market and would constitute a competitive advantage — I will come back to that later.
o Horizontal software that is "utility"-like and where we do not need anything sophisticated (e.g., scheduling).
- Software we are not building:
o Software we could build but which would create friction with customers; the economic gains are therefore arbitraged away. (Building your own PMS is doable, has been done, and is clearly easier — the same goes for some compliance-related software but you do not want to scare your customers, you want a reassuring logo)
o Software we could build but do not have the time and resources to allocate to it.
By the way, one of the most expensive pieces of software for our industry — Bloomberg — is just getting even more relevant every day that goes by. Their first-party data and ecosystem are making them stronger, and it is clearly something you do not want to go after.
Another point that is striking to me is that our CTO has become an "industrialist." I used to have many discussions about sketches and prototyping, with product owners in between trying to get the right specs. Things have changed, and there is now a backlog of prototypes that need security enhancements, need to be interconnected, and need to be future-proofed — which is a lot of work. One could argue that a CTO is not comparable to a software developer, especially across large-scale organizations. However, while I am not worried about software developers' jobs, I do believe now that job titles do not make sense anymore and will have to be redesigned.
AI might destroy humanity one day, but in the short term, AI frontier labs are an even bigger threat to knowledge-related industries using them
What I started to worry about significantly, though, is how you manage the trade-off between frontier labs that offer the best coding assistants but are a long-term threat, versus safe models that are not capable of handling tasks as complex. So basically, it is the classic trade-off of speed versus safety.
My intuition, which is growing stronger by the day, is that AI labs' strategy is to suck up as much data as possible from domain experts, to then use it against them by competing with them down the road. It won't be long (it is certainly already done) before some AI labs have identified us as an AI-native asset manager, will review our prompts, and — with some help — will understand what we are striving for. And we do not have a data advantage to protect us. Our only advantage is execution and how we redesign our processes around AI, which is vulnerable to prompt-spying.
This has given rise to a layered approach: maybe we need to distribute our prompts widely and work on proprietary tools, so that we do not leave a neat trace with the leading labs, while also distributing workloads across LLMs — from cloud to on-premise — depending on the trade-off. If open-weight / open-source models were stronger (which is sometimes not about the model but the tools built around them), we would certainly delegate much more to them.
I would not blame large enterprises for moving slow, if they do so uniquely on what is sensitive. You should go as a fast as possible on data/processes that are not sensitive.
Are juniors screwed?
We decided to go with an apprentice who is neither (yet) proficient in finance nor in coding, sitting right between the two areas of expertise, and who, according to some media reports, would not find their place in an organization where intern work would be delegated to AI.
The real surprise was how productive she was early on. At the end of the day, humans have limits on the cognitive load they can safely carry, so you need reinforcements. Interns who can leverage these tools, working side by side with us, are already having a real impact on our operations. In the past, my experience was: you would need three months for an intern to become productive; this has been brought down to two weeks. Even though all the parameters are not mastered, AI can serve as a helpful tutor to surmount these difficulties and get work done : full understand from her side will come along the way, in the meantime, her presence is already justified.
Maybe we are just lucky (and I do believe we are!), but I think she is representative of a generation that will strike the right balance to get empowered by the tools without skills atrophy. I am not saying that will be the case for all white-collar workers, but I do agree with Sal Khan's – founder of the Khan academy - about the fact that AI should not be kept out of school; the balance should be learned.
Conclusion:
I am definitely enthusiastic, this is a time where ideas come to life , intuitions can be tested with unprecedented ease. I do wonder if big enterprises will entrust the leading labs with the data and later regret (almost certainly) it, or if they won’t reiterate the cloud/internet mistakes that led to extremely powerful companies.