How AI is Changing the Way We Build Companies (ft. Guy Wuollet and Noah Citron)

Well, Noah and I were having a discussion yesterday, which was a lot of the inspiration for this, and, and we started by talking about, uh, how many tokens each person on his team, on the engineering team, are consuming, uh, which I think was, uh, a good jumping-off point for basically a discussion on which sort of work is productive and how to think about, uh, like, firm formation.

You know, we as a venture capital firm want to invest large amounts of money in companies that need a large amount of money, and will then, you know, hopefully be fantastically successful and, uh, occasionally will be abject failures.

I think there's a whole new opportunity or space in the market for a sort of company, uh, that needs variable headcount, that can be run in a much more asset- and headcount-light fashion today because of AI models.

It does not need the equivalent of something like venture capital is, in fact, not a particularly good fit for it because the terminal outcome, the success case, is not a big enough success for most venture outcomes to, to make sense.

And so we're talking a little bit about the financing models for that.

Is it something like convertible debt? Uh, do these end up looking a bit like a modernized form of private equity, or a bit like a builder form of pod shops as opposed to a, a quant and, and a trading form of that? But I think an interesting place to start is just by asking the question of, for a long time it was hard to spend a lot of money on AI inference on models.

It has become much easier to spend a lot of money on AI inference.

And, and we were talking a bit about that shift for, for your team, and essentially how much everyone is spending, which I, I, I thought was, like, an interesting number.

[laughs]

And that's because a lot of the leading model, there are newer models being released that allow you to use a lot more computation.

They're a lot more computation-heavy, and so they are a lot more expensive, but they do a lot more, and there's a lot more of that, uh, complexity they can handle.

I think the fundamental change was that, you know, a year ago, or even less than a year ago, six months ago, we really didn't even have to think much about our token spend, mostly because our ability to scale tokens was limited.

So we were able to, you know, spend, you know, almost within our subscription limits for the most part, uh, maybe going a bit into the API pricing, but, you know, not really a significant spend.

But in the past maybe three months, we've noticed that, you know, our ability to get more work done has basically started to get more linear, or at least linear for a, a little bit longer with, uh, the, the amount of money we're willing to burn on tokens.

So now the, the question no longer becomes how much work can we do, but rather, you know, how much money we can we allocate to the token budget in order to get work done.

Mm-hmm.

And, you know, this is...

this kind of changes the paradigm a lot.

So I, I think for the first time, like, it's easier to think about token spend, uh, more like headcount, right, where, uh, an engineering organization can scale headcount.

You know, uh, assuming you have, like, unlimited capital, you can continue to scale headcount, and barring any organizational inefficiencies, you can just keep, uh, keep, keep scaling that and get more work done.

Then you have to, you know, answer the question of how much work to do is valuable, right? For, like, our given business units, like, you know, where can we alloc- allocate resources to actually increase revenue? This was not the way we used to think about it, but now it is absolutely the way we think about it.

So, you know, we see, you know, for the first time, like, I, I, you know, talk to my team about how much, uh, they spend on tokens, and every once in a while I, I hear, you know, on some given week where there was some, some heavy work being done, and I go, "Ooh, that, that could cause a problem." I had never been put in that situation before.

Um, so, you know, now we're trying to grapple with, you know, both how do we, you know, manage those costs, but also how do we decide how much we should spend, when, when is it too much? Yeah, I, I think there's a very interesting concept here which, uh, like the concept of a P&L mostly comes from finance, that someone is, like, running a book of business, and they have a profit and loss statement.

And it seems like th- that, that was never a concept for an engineering team.

Like, even if you were an engineering manager, you didn't run a P&L.