AI 에이전트가 엔지니어 조직을 뒤집는다 | Reynold Xin (Databricks), YC

Thank you, Diane.

Yeah, I think one of the things that's interesting right now is that in a way the AI agents are reshaping the organizational structure because it used to be the case that you have to have humans, you build out this pyramid of engineering team for any mature product. You have to maybe the manager, the leader, and then the senior engineers and so on and so forth, army of more junior people. They'll be contributing in code and fixing a lot of bugs. And I think that is changing because the AI agents are when designed well and we have the right harness is capable actually doing a lot of the coding work. And in some cases even the design work. So I think it would actually reshape the organizational structure to be a little bit more of an I shape where I think teams will become more and more actually in a way top heavy and have people that really understand what needs to be built but also how to build them. Whereas leaving a lot of the grunt work to be done and completely automated by AI agents. And that is a huge implication I think to the both the tech and the org structure.

I think one of the interesting thing here is that by the way now I think it's a good analogy here which is when steam engines, when the world first discovered electric motors or sort of invented electric motors, many of the factories were built with steam engines in mind. In the case of steam engine, like people could actually Google this, they had a it's actually very difficult to build a lot of different steam engines. They're pretty big and pretty bulky. So, the factories are designed with one gigantic steam engine in mind and there's a lot of conveyor belts and stuff surrounding the steam engine. So, they're very tightly packed into a 3D structure. But when electric motors came out, one of the biggest changes hey, you can build fairly small electric motors. You no longer need a single gigantic electric engine or steam engine. But because the existing factories are configured in the way to fit a single gigantic steam engine, most factory just started by replacing that steam engine with electric motor or powerful electric motor. That actually only led to fairly incremental gains of factory throughput. And over the course of like two or three decades, people start engineers started thinking about hey, how do we redesign the factory for electric motors? And that's when really unleashed the productivity gain and throughput from factories. I think a similar thing is actually happening with the software factories as well. And one of the it's actually a lot easier to create a new software factory fully embracing sort of AI tools than just from scratch than just taking a giant existing system and slap a bunch of AI in it. You still get some incremental gains. There's a lot of tasks that can be automated. But if you just think about without changing the processes and without changing maybe all the tooling and how your CI/CD works, it's actually very very difficult to get a massive productivity gain.

Exactly. It's one thing is, but don't get me wrong. It is important to replace that giant steam engine with the electric motor also, but that won't give you all the gains. The more important part is to start thinking about how do you reconfigure things. But reconfiguration is slow because you don't want to be too disruptive either. So it's actually a lot easier to create, for example, new teams, new efforts, new product lines, new organizations to be more AI native compared with maybe the existing bigger machine.

Yeah.

Yeah, exactly. Actually one of our fastest growing product is something that doesn't even have a Databricks brand on it. It's it come from the Neon acquisition and the whole point of the Neon product is that it's a PLG driven motion. It's super easy to sign up. So very different from the traditional Databricks enterprise motion.

Yeah, I was going to and Neon give you a serverless Postgres that auto scales super super rapidly and also allows you take a snapshot of the database and restore and branch off the database just like you can do with code. One other thing with AI agents is that AI agents move incredibly fast and you can use AI agents to run a lot of experiments in parallel. Many of these experiments might not work out. Some of them might. And for the ones that don't work out, you want it to be super super cheap. For the ones that might work out, you actually want to be able to run on infrastructure that can scale you to the point of going to production at scale. And historically sort of infrastructure, especially databases, were designed to be heavy weight. They were think of to support, hey, the most mission-critical applications. But Neon's approach is, hey, let's design something that is super super cheap. Because you can start very very small just getting a Postgres database. And if you want to branch off on a lot of experiments, you can do that instantly. But if any one of experiments actually start taking off and become comes maybe where you want to go into production, you just use the same environment actually go auto scale to whatever you need. So that's like actually Neon's been growing like crazy. When we acquired Neon it's about actually less than a year ago, the revenue has gone up more than 10x just in less than a year. And we're seeing massive adoption. I think mostly because of the agentic workloads. They're very very different from the past workloads.

Yeah, that's one of the key reasons. And another one is it's also powering many sort of agentic coding platforms like Replit, Vercel, and many others that are sort of coming in the pipeline. For many of these platforms they suffer from exactly the same issue I talked about earlier, which is they want each individual experiment or each app to be super cheap. But then if they do take off, they want to be able to take it to a pretty fast scale. And that it's just a difficult problem from sort of conventional infrastructure point of view.

Yeah, I think more generally and broadly than Neon, I do think infrastructure needs to evolve in agentic era, which is it needs to be able to start super lightweight. It can't be this sort of a delicate thing that requires an army of people to babysit and cost like millions of dollars for every little thing. It needs to be able to support even that approximately zero cost to begin with and when it does, whatever that's being built on top of it actually demonstrates value. Then it can actually start scaling up the cost.

Yeah, I think it's actually a great time right now for any sort of disruption infrastructure, honestly, because pretty much every piece of infrastructure was designed to be super heavyweight. Even the word infrastructure sounded super heavyweight, right? It reminds you of PG&E and maybe oil pipelines. And I think there's a lot of architectural evolution with the cloud and with agents that you can now actually start thinking about it. Many of infrastructure became super heavyweight not necessarily because there's a fundamental sort of technical limitation. It's mostly because it was designed initially just for high-value sort of services. But now with agentic coding, there's going to be maybe the individual value of this each service or each experiment is very low, but in aggregate, they can be very large. So, there's sort of a opportunity to target the very long tail to be building something pretty valuable. And that's just something most incumbents have never even thought of. So, we have a very difficult time transitioning into.

Definitely.

All right, thank you, Diana.