Aaron Levie 谈 AI 采用与企业工作流 | The a16z Show

The board goes to the CEO. What does the board say? “We need more AI.” And what does the CEO say? “Okay, I’ll get a consultant to do more AI.” Then they have some centralized project that nobody knows how it works. They haven’t aligned their operations, and those things will fail.

The funniest concept is that the more code we write, the fewer engineers we would need. It would be the opposite, because now your systems are even more complex than before, which means you’re going to run into even more challenges when you need to do a system upgrade, when there’s downtime and you have to figure out, “How do I fix that problem?” or when there’s a security incident. I mean, we’re just getting started with the jobs on this front. They’re going to hit a wall at integration.

The thing that’s not different about AI—and that agents don’t fix, that nothing fixes—is that any enterprise of 1,000 people or more, or that’s older than 10 years, is just massive stuff sitting there waiting to be integrated. You can’t just say it’s going to integrate. AI actually doesn’t help to integrate anything.

Hey, we are here moderating the situation live, and we’re very excited to talk about a bunch of AI stuff. The 3 of us are here today. There’s me, Steven Sinofsky; Martin Casado, who will wave and say hi—

I’m Martin.

—and Aaron Levie, who is working on the elevation of his hair today. We’re excited about that.

It keeps getting more vertical. I thought I could tame it, but it didn’t work.

Is that just a token issue or a number-of-parameters issue with your hair?

Too many parameters.

Okay, I have the same thing, but in reverse.

Hey, listen, you have a distilled model.

There you go. Mine runs locally.

There’s been a busy week of things, but we want to bubble it up a bit and start talking about where things are heading. I’ll kick it to you, Aaron. Start where you’re most excited at this moment, because you’ve visited a ton of customers this week and learned a lot. You’ve shared a lot on X, but I think you’re the most in-the-trenches CEO who is really talking to customers every single day in the enterprise, which is what the 3 of us tend to look at the most.

I think my job these days is to bring reality to the Valley and then bring the Valley to reality as much as possible. It is a crazy divide that exists at the moment.

Take it back. I actually think it’s super interesting. What is the gap caused by?

I think the gap is caused by the styles of work that exist in Silicon Valley and in engineering roles versus the rest of the world. We’ve talked about this a couple of times in different forms, but the technical aptitude of an engineer is insanely high. The level of being wired in to what’s going on on the internet is insanely high. The ability to use your own tools and make your own choices is insanely high. When things go wrong with the systems that you choose, you can quickly debug them and make them work for you.

Then, obviously, you have all the benefits of the fact that the models are really good at code and the work is verifiable. So you have 5 or 10 things that make agents work in an enterprise context for engineering, or even in a startup context for engineering, but there tends to be a gulf between the way you work in engineering and the rest of knowledge work.

A lot of what I see is trying to figure out how to bottle up all of the greatness we’re seeing from coding agents and from agents that use computers. How do you bring that into the enterprise, where the workflows are quite different, the users are less technical, the data is much more fragmented, and the systems are much more legacy? That tends to be the divide.

It’s not even that we’re talking past each other in one of those classic government-versus-industry ways. It’s just that there is a pure workflow and technology-stack divide. That’s why it’s going to take a number of years for this diffusion to roll from what we’re seeing in Silicon Valley and in tech startups all around the world into the rest of knowledge work.

Martin, just to build on that, you have a ton of experience in big companies. One of the other issues, though, is scale—the difference in scale at which Silicon Valley operates at the startup level versus everyone else.

I also think that these secular trends, like the internet, actually start with individuals. Big companies tend to make decisions centrally, and AI is one of the fastest-growing secular trends. There are probably a lot of individuals in big companies who are doing it, while the big companies themselves don’t even know how to think about it.

When you hear stats like MIT’s claim that 95% of AI efforts in big companies fail, that’s clearly silly, because I’m sure everybody’s using ChatGPT very effectively. What they really should be saying is something else.

Listen, I sit on these boards, too. The board goes to the CEO. What does the board say? “We need more AI.” And what does the CEO say? “Okay, I’ll get a consultant to do more AI.” Then they have some centralized project that nobody knows how it works. They haven’t aligned their operations, and those things will fail.

When we say scale, we often think about things like system scale or the number of people. I think the secular trend is scaling wonderfully, which is reflected in the numbers of these companies. But organizations don’t know how to adjust the agile processes that have been worked on for a decade around data, governance, operations, compliance, and so on. That’s where I think Aaron is right: there’s a gap between the secular trend and the organizational decision-making body.

This is something that we track very closely, because we’re starting to see, in the last few months, some real inroads into the enterprise. But it’s tepid. One of the reasons is that there’s a lot of skepticism. The board wants AI, and CEO AI failures have created some amount of bruising, which is requiring these companies to get past it in order to make a second attempt. I think this is exactly where we are.

I 100% agree with that. It’s good to start with agreements, because we know how quickly those fade.

That’s the only time we’re going to agree.

Exactly.

I think maybe one more point on the board—for agreements, maybe you guys would agree. There’s also a very interesting dynamic. I’d say this is a minor one relative to everything else, probably 5% of the problem. It might be more fun to talk about the real problem, but as an aside, there’s a fun dynamic.

You go to an engineering team, classically, for the past—Steven, you can take us back in history on this one—and one of the easiest ways to stall a project was to get into the architecture fights: what language to use and what architecture path to go down. That could take months and months to work through as your teams figured it out.

Because of the pace of change in AI, you actually have this incredible dynamic where the labs are obviously leapfrogging each other so frequently, but without the exact same paradigm for how you should deploy agents and how they will work. Is the agent harness in the computer, or is it outside the computer? Do you run it in your cloud? Is it hosted? What tools does it have access to?

We’re not at a point where these are completely fungible technologies, and that actually creates a bit of paralysis. As an enterprise architecture team in the real world, you’re thinking, “What horse do I want to get behind, and which architecture path do I want to choose?” I’ve been burned by doing the wrong thing in AI maybe 3 or 4 years ago, going down some path that is now deprecated or no longer the right strategy.

To some extent, I think it’s fine, because there’s still so much upgrade work people need to do in their infrastructure, systems, and data. But this is an interesting dynamic. I’ll have conversations with CIOs and their AI teams and ask, “What are you using for your chat system or your core agent orchestration?” They’ll say, “We’re in the middle of a debate between these 2 or 3 paradigms.”

You hear that across almost every single customer, because there is a nervousness about whom you get in bed with and how much you fully lock yourself into one particular path. We also know that if you don’t lock yourself into a path, you’re building for duality, which also takes a lot of work architecturally.

I actually—sorry—I like the idea, and so it’s kind of like this fusion or this hybrid model. What we’re seeing instead is, instead of viewing AI as software—yes.

Just view it as a user. Instead, take your product, make it a CLI tool, and have the AI be an agent that actually uses it. You’re not fusing the two; you’re just making it more useful for AI. This is a very, very significant architectural and mental shift, right?

We started as a pure product, and then we didn’t quite know what the end thing looked like. So we created this AI-software hybrid that hasn’t worked. Now we’re kind of going to the agentic model, which basically means the agent is going to be whatever—it’s going to be Claude Code or whatever—and my product should just be something that can be consumed by that. That’s the actual modality.

But within a year, you’ve had to rearchitect your software twice. I think no matter how many places you look in the industry, there’s this dilemma of trying to figure out what the final form looks like. And Steven, you will remember all the hybrid versions of cloud.

Remember remote desktop and all these things? I think we’re speed-running that evolution to the final form. And I think people in Silicon Valley don’t quite appreciate when a big company says, “Well, we have to map out the bet that we’re going to make.”

Because that just seems stupid. If your job history is five two-year stints at startups that went from seed to Series A to acquisition or something, you didn’t learn anything.

Well, you never—your frame of reference is not picking an accounts-payable system that’s going to last 40 years.

Yeah, I actually have all these visual aids today. So here’s the ultimate engineer in Silicon Valley: Gilfoyle.

And Gilfoyle is like, “I don’t want to talk to anyone. I will just write the code, and you go do your thing.” The thing is, you have people in enterprises saying, “I’m going to use the model and do my thing,” but they’re going to hit a wall at integration.

What’s not different about AI—and what agents don’t fix, what nothing fixes—is that any enterprise of 1,000 people or more, or that’s older than 10 years, is just massive amounts of stuff sitting there waiting to be integrated. You can’t just say it’s going to integrate. AI actually doesn’t help integrate anything.

Well, Steve, it’s actually a little worse than that. Right now, many companies are incentivizing people to use AI by counting tokens.

My coworkers and I have agents do useless tasks just so that we can count tokens. I’m not joking. You get whatever you measure, so it’s the extreme form of what you’re saying, Steven. You have people being fake-productive and producing a lot of potentially problematic artifacts just because they’re using these models.

When the internet happened, all of a sudden every company needed websites. A very famous moment in time was not too long ago, when every internal team had a team website. They went out and got a vendor to write HTML and create their site, and then there was a team.

There’s nothing dumber than having a team website at a large company because a team gets reorganized six months later. Companies were just filled with thousands of these dead websites. “Dead web” was the expression.

But we should drill into your integration point because I do think this is something for reality to settle in in the Valley on the real-world journey to becoming fully agentified, what that’s going to take, and what that’s going to look like. Your point about being passed to a different human based on the role you needed to interact with is important.

Agents basically don’t have any real exception yet for the agent having the same problem. As you pass through different humans, it’s a different set of access controls that each human has. If an agent can bypass any of those steps, that’s how you instantly get the security risks. You need to pass through those steps so that you don’t accidentally get to the wrong piece of information and so there’s verification.

There’s a lot that you need to build out for agents to be able to work with all these systems. Most legacy environments don’t have the most authoritative access controls. As a human, you’re always going and saying, “Hey, Sally, can you share that thing with me that I don’t have access to?” Or, “Hey, Bob, what’s the number inside your data system for this question?”

If agents just get the exact same permissions that you had, they’ll run into these walls everywhere and won’t be able to complete the process. Unlike a human, they’re not going to know to go talk to Sally or ask Bob the question, so they’re just going to be stuck.

What’s going to happen is that you’re going to have a lot of agents that don’t have access to the right data. They’re working through systems that aren’t the real sources of truth for the information. They’re getting the wrong number and the wrong document. This is the real work that enterprises have to go through right now.

The good news is that it’s actually a great time if you’re a startup because you get to know all the problems right out of the gate. You can design your organizations to try to avoid this. But for big companies, there’s real work that goes into upgrading systems, modernizing the technology environment, and making sure that agents have access to the right data, documents, and context to do their work. That’s the work ahead.

There was this headline about OpenAI’s Codex working with Accenture, Deloitte, and all the major system integrators. There were some snarky comments online that fascinated me because they showed how great the divide may be between the rest of the world and those in tech.

To me, it was the most obvious announcement of all time: a large enterprise is going to have to go through the change management, systems implementation, and technology integration required for these agents to work. People thought it was ironic that we need people to implement the agents that are going to automate the people. No, that’s exactly how it works.

You do need to do lots and lots of work to be in a position where agents can actually help you do any of the automation. There are going to be businesses doing this for decades. It’s going to be an incredible opportunity for the next generation of firms, as well as existing ones that lean into it.

Let me throw this out there. First, I think people shouldn’t celebrate when those systems fail, because they will fail. A lot of them are going to be top-down mandates where someone picks the most acute problem in the company and thinks, “AI is going to solve that.” The IT people are going to be like, “Oh, God, that’s the worst system to try to do that with.”

But the CEO, CFO, or whoever is going to be obsessed with solving it. Most likely, the customer-service person will be obsessed with it. If I were advising a startup specifically on how to enter the enterprise space in that way, I would definitely be thinking about not just building a company that, in step one, only works with all the headless SaaS software that’s out there, because there just won’t be any. The thing you can do is structure the value that you offer. And this also applies to what you go do in a company. It’s really a fork: is this an agent that is seeking information and presenting it to some human, or is this an agent that’s supposed to go act and do something? Is it acquiring or is it doing? Because it turns out that’s what happened with the internet. The internet got very valuable when the first step was just providing access to things to people. All of a sudden, all the sites that literally did integration—“Hey, I need expense reports viewed by department,” or “I need to see our current inventory status across the two companies we’ve acquired”—became the integration point. And then, once you can bring them all together, you can add an agent that has an approve button or a reject button or something like that.

No, no, I think this is a very legitimate view, but it’s not the only view. In light of AI, it’s not the only compelling view. The current view is that AI is software that works in a different way, and we have a current set of systems that we have to integrate this new type of software with so that it can get access to data and do things in a safe way. But the end-to-end argument is that these LLMs are non-deterministic, they’re smart, and they deal with the long tail of complexity. It turns out those are all things humans do, too. We’ve spent 40 years building interfaces, processes, and design to deal with messy humans. If you view an agent more like a human, hire the agent, give it its own email address, let it access documents like humans can, log in, and request the things that it needs, then it will draft on all of the processes we’ve put in place for humans, not for software. If you view them more like humans and draft on the mechanisms we put in place for humans, they’re much easier to integrate.

I think we all agree with that. The issue is that humans have a bunch of extra benefits. Humans have context that they get for free by virtue of keeping track of the relationships they’ve built in the organization and knowing who to tap on the shoulder when they need something done or need information. Agents can work in parallel at infinite scale, but they don’t know who to tap on the shoulder.

Hey, I listen, Aaron, I am all for agent onboarding. The agent comes, goes to orientation, and the CEO gives it the culture discussion. Every department does its pitch: this is what we do. Given the technical nature of these agents and how much entropy they have, we’re going to have to go through the processes that we’ve refined around humans.

No, no, totally agree. What I love about that is that it’s the same argument that humanoid robots will be the best kind of robot: we have a whole world designed for humans. I saw a robot go into an elevator, and there was a button-pushing robot on the elevator because the first robot was a tiny little thing like a Roomba on the floor and couldn’t push the button. The same company invented a device you buy for the elevator that pushes the button. They said the elevators don’t have systems that they can hook into as a robot. There’s no Wi-Fi press-the-button-in-the-elevator capability. There’s no API for that. There is no headless version of the elevator.

The big news last week was Salesforce going full headless. They want to be used everywhere across all the different agents. I see that as a bellwether because, as Salesforce goes, so does a lot of enterprise software. People will have to figure out the new business model in this headless world: do you charge an API tax, or is there a seat for the agent? It gives software platforms all-new use cases, because the headless user can be 100 or 1,000 times the scale of human users.

An agent is just an entity. It’s another license, with a different license model perhaps, but it has to have an identity. It has to have a certain amount of access rights. An agent is never going to have more permissions than the person who’s getting it to do something. Otherwise, a human could just get the super-smart agent that knows everything the human isn’t allowed to know. There’s no way around the fact that it is another seat.

But first of all, the points that Martin made about the LLM stochastic model—you’re not going to be able to figure it out. It’s not like a record in a SQL table that you could just apply ACLs to. It’s actually like it could be words in a sentence or just the number that shows up.

And so I actually think that whole discussion about headless, for me, made the SaaSpocalypse seem even dumber than it already was—and it was already dumb. At first it was dumb, and then I’m like, “Oh my God, it’s actually much dumber than I thought it was in the first place.” Because you’re just going to have this explosion.

Now, someone might come up with a very clever pricing scheme where agents somehow cost less because maybe for the first 5 years they’re read-only, or they’re always tied to a person or something. But it is another seat. There is no way around it.

And if you’re a SaaS company, you’re crazy to try to say, “Oh, just use the credentials of another human.” That would be bad security practice from the get-go. Exactly.

So, this is playing out in many domains. You can even make the argument that a headless SaaS doesn’t make sense. Here’s the argument. Let me give you an example.

If you use OpenClaw, do you know why you use a Mac mini with OpenClaw? Number 1, for iMessage. It’s for the integration. There is no headless version, so you’re just going to use it. The second one is very interesting: if you’ve tried to use headless browsers with agents, the problem is that all of the websites have anti-scraping measures, so they don’t work.

If you could argue that it’s just Salesforce—not headless—it will go to a—

Wait, wait, wait. Do you literally mean the agent goes to the browser?

Yes.

Oh, no, no, no. I’m taking the other side on that one, big time. Let me simplify the argument so we can actually have it.

Today, if you use an agent like NanoClaw or OpenClaw, you could use a headless browser. Let’s say I wanted to look up the value of my house on Zillow. The headless browser simply doesn’t work because Zillow is so tired of people scraping it that it detects headless browsers. Totally.

So, the thing that works is that it pops up Safari and uses proper Safari directly, right? And then, all of a sudden, it works.

But no, I would just say that any software that has a good API, the agent would absolutely prefer to use the API. Then you pop into the browser the moment that you run into some execution problem.

Steven, as a fantastic long-term computer science and software guy, however, these models are trained on data and RL environments from existing software that didn’t have those APIs.

And right now, if you actually look at the adoption and the use of these agents, they look far more like what a human would do than what a program would do. So maybe you’re right, but A, that’s not what we’re seeing.

You can honestly make the end-to-end argument when it comes to data and all of the controls on the internet. To Steven’s point, all of the existing controls are just going to be the same, because these agents are actually going to have the same actions as humans. The APIs of any software provider will follow the same access controls as whatever the user is that is—

Right, but they have to rebuild it. It’s like you’ve got this existing app, and all the models are trained on all the people using the app.

Well, on that point, it’s a totally fair point, but I would guess that over time you’re going to have very accurate, rigorous data sets for models to be trained against the MCPs of every SaaS platform and the APIs of every SaaS platform. Already, they’re training against all of our documentation on our products and our APIs.

But I just think, to me, it’s more of an inefficiency of navigating through pixels versus just doing it directly.

And the thing in systems, Aaron, is that layers never go away. They just get layered.

Well, on that, I’ll support your point 50%.

If you need to do a search for a document, our search API is going to be a faster way to do it than clicking through an interface. But to support the point, the new Codex computer use on the desktop is just insane. Steven obviously knows everything about how it would work.

I saw my ability to move a mouse and then this other sort of mouse moving and clicking things, and I was like, “I don’t understand computers anymore.”

Right. To your point, Martin, my first instinct was to use it for something where I know there’s no available API. So I did actually use it right away for something that I don’t have access to the API for.

An agent, over time, is probably going to have to figure out whether there’s an easy MCP or CLI for an action. If not, then I’m going to pop into some kind of cloud browser or cloud computer, or maybe a local thing that I can parallel-track, and then go and execute that. That does seem like a reasonable architecture.

But I still think that I’m going to pound the Salesforce API massively in headless mode, because that’ll be an efficient way to go look up records.

I think you’re both saying the same thing, but there’s just a time dimension. There was a moment on the internet that I was thinking about when I was seeing that timescale difference.

Suddenly, the 8 million quadrillion pages about how to use Word and Excel that we had written over the years and posted on the internet—we used to ship them with the product. People would have them on their hard drive, not connected to anything, and they would say, “How do I make a pie chart?” or whatever. It never worked. They could never find the thing that they wanted.

But what happened with the internet was that everybody finding it caused us to make better documentation. It also caused Google Search to get better at finding the information that it needed, which then completely changed the way that we thought about doing documentation.

I think that with headless, especially for the kind that’s just finding things, it’s going to really change the way that information is exposed. The way Salesforce exposes it today through a headless API, I’m almost certain, if I were to go look at it, is going to look like the developer API behind a CLI. It’s going to look a lot like that.

But that’s not at all how humans using Salesforce interact. A human is trying to solve something like, “I’m standing in the elevator waiting to go see a customer. What is the stuff I need to know?” That mapping is completely different. So that API is going to really change as a result over time.

Yes, I think the API changes for sure. I agree with that, but unlike the humanoid comparison, where the physical world has interesting physics issues that you eventually run into, the digital world doesn’t.

At some point, your agent can run in parallel 500 times. If I want to do a market map of customers across the Fortune 500, that agent can fan out and do that work in a way that I can’t as a person in a browser. To some extent, agents let you bend the laws of normal, human-based workflows.

That’s why I think the APIs may eventually evolve, but not obviously in the direction of the end-user product. They may evolve more toward an agentic set of workflows: What is that agent looking to do?

Well, but Martin, I think we can jump in and just say, “Wait, you didn’t describe anything new. You described an architectural problem with today’s software, which is that its API and performance gate were based on how much I can type.”

That’s the point I was making: our help system was designed around how much we could ship on 1 CD, and it had no data about what people were trying to do and no context. But it didn’t change the problem, which is that I needed to make a chart.

Yes. Exactly.

So, 1 real example of this: we launched a Box agent that has much more capability built into it. One of those capabilities is that it searches across your whole Box environment.

But it doesn’t have the same limitations of a human-based search, where you type in 1 query, get back a set of results, and look through them. It fans out, does multiple queries, can look through hundreds of results instantly, and does its own reranking of them.

And so that's just, again, you wouldn't want to be rate-limited by the same process that a human went through. Which is where the humanoid robot is: you're kind of willing to be like, “Okay, the humanoid is still going to walk into the elevator, and it's still going to press the button.” When actually, in an agent world, you're like, “No, no, I just want you to go and instantly press the floor that I'm going to.”

Yeah, but we should be very clear. I very much agree, but we need to make a distinction between whether you would ever build an index that's only for AI and not for a human. I think that's less obvious.

Yeah. So clearly, there are performance gains based on automation. We've got to evolve our architectures for those, but if you find a great way to index documents and you don't expose it to a human, I think that's—

Yeah, you got to—yeah, exactly. 100%. Well, this kind of moment probably reinforces some of Steven's internet analogy on documentation. There is this really interesting thing where, as we've been building our next set of agents, we first gave them the current set of tools. We saw how they used those, and then eventually we realized, oh, there's actually an even better way that the agent could do it. So we improved the underlying scaffolding, and then, by the way, that will actually help the end user also. So it does let you contribute back into the mothership of technology improvement that does lift all the boats of your users.

Let me ask this. It occurred to me as you were saying it: I got all tense when the idea became, “Oh, we have 10,000 people hitting our SaaS system today, and we've got it all working, and it's all great. But now we're going to have 10,000 new people—the agents for each of those 10,000 employees—and they're actually hitting it 500 times as much.” Okay, so that SaaS product will collapse. That's the first order, because it wasn't architected for that volume.

We saw this with all the BI tools. When all the BI tools came out, all of a sudden they were looking at the SAP data and trying to snapshot it and absorb the whole thing every night for a new kind of set of slices and dice it. All the people making ERP were like, “Well, we don't do that.” So they had to go build all of this themselves because they had the knowledge of the data. Their API just wasn't designed for that kind of workload.

My thing to throw out there and fight about is: what does change management look like in a company? Because you can't let loose an agent that hits the system at 500 times the humans. And it's not a token thing. It's an actual, “Wow, we don't have the network bandwidth and the throughput to handle 500 times for any one of our customers.” So what happens?

So, I've got a provocative adjacency, which you guys can tell me if I'm going too much on a tangent here. Here's my provocative adjacency: I don't know if having more agents is that big of an architectural shift. I just feel like we understand—whatever, if it's read-only data, you cache it. All the state issues are around mutable, globally shared state. We understand the limits of those, and we know how to architect around those. We had to tackle all of those things when we went to the internet.

And so, if you build your system not to handle it, you suck at building the system and deserve to go down. Just go build a system that doesn't suck. I just feel like this is kind of standard computer science. However, I do think agents introduce something that organizations technically have to deal with. Let me just give the analogy in code, which is—I think, Steven, this is what we call mogging on a question.

I don't know.

You're being a bad question mog. I have no idea what he just did, but I'm looking forward to how he magically made the problem go away. But go ahead.

No, no, no, no, no. The problem is there. I just think we know how to go from 10—

Yeah, it's there for stupid people. We just got rid of the stupid people, so now everybody is smart.

No, no. Okay, so let me give you an example for coding. This is where I actually think there's a shift in how work gets done. When you code with AI, your code kind of gets worse over time, pretty materially. And so it's almost like you're introducing as many problems as you are solutions. I don't think we've actually figured out how to manage that. Does this make sense?

100%—in the whole world right now. Yeah.

I mean, this is the reasonable question: if you're using AI, yes, you're productive, but are you creating more problems than you've actually solved for solutions? And I do think that there's this open question when it comes to using agents on existing systems for creating things, which is: do we know how to wrap the growing set of entropy around that?

I would say, anecdotally, watching companies struggle with AI coding—which, of course, I'm very close to many AI coding companies; I'm clearly very bullish on it—I don't think we know how to do that yet. And so the agents on a system, I think we can tackle those with known techniques. Using agents for long-running things organizationally, where the universe is kind of as clean as it was 3 days after you started, I'm not actually quite sure we know how to do that at all.

Well, I love that point because that gets back to where we started, which is the difference between scale and not scale. And why it's perfectly rational for big-company people to be like, “No freaking way is this coming into our company.” Because the wheels are going to come off a big company, or a division in a big company, or a product in a big company at any minute.

Marty, we were both giant-company executives. Literally, we woke up every morning thinking, “Oh, the wheels are coming off today. This is the end of it. I'm getting fired by 5:00.” Whatever I left yesterday thinking we were 3 months late on, we're now 9 months late. And that's a typical day.

The reason that doesn't happen is because you put constraints all over the place.

Which is exactly why Gilfoyle can't work at a big company. It's also why all the one-shotting, vibe-coding kind of people have no problem saying it's fine, because they've never had to live in an environment where the constraint was to prevent the whole thing from imploding.

And I feel this is so critical, Steven. Again, this is going to sound a little tangential, but it feeds into this: I feel like core technologies catered to some human need. The internet catered to connectivity, and social networking catered to vanity, and I feel like AI caters to our need to be productive. So we feel like we're being very productive when we do all of these things, but we may actually be creating mounds of extra work to do.

Well, Aaron, you're deploying AI right now. Box is all in. So tell us—share a story of the wheels coming off or not coming off.

Well, I think we're probably in the more pragmatic part of the continuum, which is why we don't claim that that's a 10-times productivity gain to our engineering team. It's like, no, because we have a lot of guardrails in place that create these constraints automatically in our system. We still rely heavily on code reviews. We still rely heavily on security reviews.

Are you guys coding with a rock and a chisel and stuff?

It feels like that sometimes. We have chalkboards and— But no, we had this new feature that we launched, and I was like, “Go, go, go, go.” AI built probably 80% to 90% of the feature, and the thing that slowed down the release of it was that we had to do a full security review, because we can't let there be any accidental code injection into the thing that we created.

So there's a lot of stuff where you go super fast, but then you're still rate-limited or constrained by some other part of the process. Until we figure out that other part of the process—security review being one, actual code review being another, or even your pipeline for getting things into production being another one.

We're doing quite a bit of retooling of the whole product-development life cycle, but I don't think that it's a 5-to-10-times gain. I do think it's a 2-to-3-times gain, maybe, across the board. You are still rate-limited by how quickly you can review this stuff and check on the work.

I do think that Martin's pointing at a big open topic across enterprises. To some extent, engineers will face it first and find the right equilibrium. The harder part still remains in the rest of knowledge work. This is why, if you're in accounting, we don't quite yet know when you can take your hands off the wheel doing a full accounting audit because of AI.

What you can do is have the AI comb through unlimited amounts of data to find anomalies that would alert your accounting team to, “Oh, we actually have to go dig into this.”

That’s awesome because that’s only a net-new level of visibility, versus the part of the accounting process where you’re doing a fine-tooth comb to make sure every single number is accurate. That’s probably still humans right now. So I think the key is: where do you find the productivity gains? I do think that if you’re a CEO, a board of directors, or a management team, you’re trying to figure that out, and you’re also getting confused because Silicon Valley is telling you all the things.

You have to figure out where the productivity is most potent, where you can actually get the gain and the success with less of the downside. I think, as an industry, we’re all figuring this out. By the way, this is why I remain unbelievably optimistic on jobs, because I think we’ve gotten it wrong in thinking about all the places where you’re going to remove humans from this. You still need a human somewhere in the loop.

Maybe the abstraction is a little bit higher, and you don’t need a human in the loop at every single stage where you needed one a year ago. But you do need a human kicking off the process, reviewing the process, and incorporating whatever the work was. That creates a tremendous amount of opportunity in jobs across these organizations.

Oh, let me jump in, because I have a whole bunch of visual aids I brought today to make it exciting. We got a bunch of comments on the MTS Live thing about people agreeing with you. I don’t want to let that slide, because we complain about not agreeing with you, but here, to your point, this was a book in the 1990s called The End of Work.

It came out about 6 months before the internet hit. The whole thesis was that the technology revolution was a complete bust, we got no gains in productivity, and now there were going to be no more jobs because the economy was stagnant. The guy called himself a futurist. One of the neat things about this whole AI moment is the number of things that, when you hear them the first time, you think are stupid, and then you go back and think about them and you’re like, “Oh my God, it’s way stupider.”

This idea that AI just gets rid of jobs is as ancient as the accountant you talked about. One of the things people thought was that computers would get rid of accountants. That was IBM’s pitch in 1965, but what it actually did was, “Oh my God, we can do so much more with accounting now that they’re not literally just adding numbers all day.”

When you look at creating information, synthesizing it, and all of that, AI is an accelerant for a person who knows what they’re doing. Companies are suddenly going to want more of those people creating more of that information. Not to mention the fact that if AI is creating valuable information and there’s more of it, then more people will need to consume it to do something.

The essence of a company is acting on information. This idea that information is just going to get produced easily, be in surplus, and not be used makes no sense at all. As you know, in the unstructured information world, the problem is that you can make it, but consuming it effectively is the gating factor.

We had a conversation with one of our board members, who’s the chair of our audit committee. He’s a CPA, and he was telling us about early in his career. I can’t even retell it because it felt so manual. I don’t know how the world worked before all of the modern technology, but he was explaining the CPA’s process, and it seemed like the most manual thing of all time.

Steven, I think this is right out of your book: It was actually quite simple in the amount of things you could do because of how undigitized and relatively manual the whole thing was. Computers only made it more complicated and more comprehensive, and thus created even more jobs because of the complexity that we introduced.

You can see how easily this shows up in so many areas of work. We can now afford to make things more complex. If you make things more complex, you eventually run into new constraints around who can understand that complexity. To me, it’s the funniest concept that the more code we write, the less we would need engineers. It would be the opposite, because now your systems are even more complex than before.

You’re going to run into even more challenges when you need to do a system upgrade, when there’s downtime and you have to figure out how to fix the problem, or when there’s a security incident. We’re just getting started with the jobs on this front. Listen, we’re a few years into this, and you can also look at the data. What companies are hiring the fastest? AI-native companies are hiring like crazy.

I remember there was this early prognostication that AI writing code would get rid of infrastructure. It was going to commoditize infrastructure, which is a very strange prediction given the fact that more software is being written than ever before. Sitting on the boards of a bunch of infrastructure companies, including some that have been flat for a while, I see that they’re all doing fantastic because there’s so much software and so much more software out there now.

If you look at the data on the ground from companies, it’s more software. The AI-native companies are hiring the most, so it’s very clear to me that we’re in an expansion phase.

And maybe my only final point on this one, at least, is that I think people have a somewhat myopic view in Silicon Valley. We think that engineering jobs mean going to work at Google, or at some other technology company or startup. We’re wired into that because of the ecosystem that we’re all part of.

Then you forget that John Deere is trying to make automated tractors, Caterpillar is trying to have AI systems, and Eli Lilly is trying to design even more pharmaceutical therapeutics. You can go through 5,000 other companies. They’re going to have the next set of engineers who use Claude Code, Codex, and Cursor to automate even more of their businesses and design and develop more software for their workflows and systems.

It might be that you don’t go and work on a social network and improve the social network algorithm. You go work at John Deere and improve the intelligent farming algorithm. We just have to recognize that Marc Andreessen predicted this 15 years ago: Software is going to eat the world.

What that means, though, is that everybody’s going to have lots of software. This gives everybody the ability to finally have lots of software, but you still need an expert or a semi-expert to prompt the agent on what to do, review its work, and manage the system that it builds. All of the predictions that say not to go into coding or software engineering will be proven quite wrong.

Well, we have a lot of people who like technology, though, who are also creating that.

Right. So this is an article, “Fighting the Paper Chase.” Time magazine—every kid in high school read it in 1981. The whole view of what computers would do was that they would automate the paper in a company. The first generation of computing was literally taking paper forms and turning them into something on a screen, then printing them out, and making it all easier.

You fast-forward, and it’s all of these things that you just said, Aaron. There was an era when lawyers didn’t type, so they had legal assistants called paralegals who did all the typing. Then some students at Harvard brought a computer into the classroom. This is an original laptop from the early 1980s.

They brought this computer into the classroom and got thrown out for using it. They used to go to law school and write essays in longhand in a book, and then the professor would have to read them.

And now, of course, you just type them, and you have access to the database of all the citations. That's exactly like how nobody deals with a lawyer who isn't using Track Changes on your contract, right? And, last I checked, there are way more lawyers today than there were 30 years ago. Every human lawyer you talk to is a computerized lawyer. Their citations come from the internet, their information in the brief comes from the internet, and they type the brief.

Going back to my myopic approach, I think we may over-assume that everybody's job is just inside of Microsoft Word and they're just typing a Word document. Most of the time with lawyers, I'm strategizing something, or they're working through a complex analysis of a situation, and it's not like I could go to an AI for advice. That would probably only increase the chance that I go and then call a lawyer to say, “Hey, what do you think about this situation that I'm dealing with?”

A lot of these jobs just have a lot of context that isn't sitting just literally on the computer doing all the work. They do have to touch grass as a part of the job. AI will help automate the creation and production of the content and the review of the information, but then it still has to be incorporated into the real world of real value production.

I feel like we're live and we're supposed to end at 4:00. So what I'm going to do is just say we're live and it's 4:00, and I guess that means we just stop and some lights fade or something. None of us have done this before. We don't know what's supposed to happen. But someone is waving at me and smiling, saying, “Yes, I think you're right.” The smile means stop talking.

Okay. All right. Well, it was great to see everybody. Bye, everyone.