Why AI Agents Hallucinate — and How to Actually Control It | Wiley Jones, Doss CEO

Self-evolving software still sounds to me like science fiction. It's almost like a different species of software.

It is. It's a new speciation. That's very true. I agree. Why are our applications themselves not self-evolving? I go into my Notion and my Notion is evolving itself. It's just, it's there. If you fuse these 2 things together, you put the lifecycle of the application and the application inside of the same runtime, you will get full self-evolving software. There's a bunch of errors coming through on our wholesale orders channel. Create a branch on myself. I start testing it, but I'm going to flag this. A human must review it because I'm touching a hot path. We process $1 million of orders every day. If I break this, break our sales flow, we'll turn into these gardeners of sorts cultivating and letting these systems flourish and grow. Someone's like defusing a bomb and you ask the agent, am I supposed to cut the red wire or the green wire? The agent sees that they don't have access to information about the red wire, but it's actually the correct one to cut. Do you tell them the answer? They can't know this. They're not allowed to see it. But I do know the answer. When you have a great product and it's super thin technology, you're going to get completely wiped out by technology companies. There is more to build now than there ever has been in the history of history. Best time ever to be building stuff, full stop. Deeply understanding people and how to solve their problems is still very durable for a very long time. I haven't written code in months. You're more so sculpting it now. It's not artisanal. You're not like touching every single line.

Today I have Wylie Jones. He's the CEO of Doss, D-O-S-S, and his team just raised $55 million. That's your speed. Congratulations.

Thank you.

And we're going to talk about what he's building and why it matters. Wiley, welcome.

Glad to be here. I appreciate it.

I've been researching on your website and I find your messaging on your site very interesting. Like it says DOS Operations Cloud is the ERP evolved, but what is ERP?

Yeah. So the thing with ERP is that it is a, let's describe it as a specific 3-letter acronym. that we think does justice to the problem set that we're solving and the solutions that our customers need. So a lot of times people will think of this in juxtaposition to what came before, which is ERP. ERP stands for Enterprise Resource Planning, uh, which doesn't really sound like it means anything. I'm not really, you know, if I think about those, like those specific words in there, um, I'm planning resources for enterprise, not precisely sure what that means. And in practice, the way they end up getting used is that a lot of organizations use an ERP to manage the financials of their business as well as the physical operations. What we try to focus on with ARP is building enterprise applications that are adaptive. So if I'm a company and my strategy changes over the course of a 5 to 10 year period, I obviously need my applications to adapt to that. We go in and sell new products and new sales channels. We go into new markets and new geographies. We want our platform where all of our resources are orchestrated to be adaptive. And that is the entire premise behind what we've built with ARP. It's a, you know, it's a product concept. And then Operations Cloud is the full suite of solutions we deliver around that. So we think it's really just the evolution of what ERP was always meant to be, um, and has not been able to live up to in the last few decades.

In your opinion, is the ERP today different from last year?

As a product and as what we do as a company? No, not really. It's just that we continue to refine the messaging to make it really clear to our customers, really make it clear to the market precisely what the use case is. And when we said, you know, this adaptive ERP and data platform, what we were saying in the past really was trying to make it clear that we were solving a problem. Around how they manage structured data for their business and then how they build applications on top of that. And what we realized in talking to our customers and talking to the market more broadly is that the world really sees those as one thing and how they were combined. And so we really needed to position it for them to make that clear.

Hmm. That's interesting. Is that, is that a category that existed before you guys or it's you created it?

Okay.

Got it. Later, later on, on your website also, I found something very interesting as well. More value, no ERP tax. No support fees. Our value engineers work with you to deeply understand your business, custom build your workspace, right? And provide 24/7 support. What is a value engineer?

So that's one we didn't create. That's a concept that's been around for quite a while. Value engineering is something that happens in pre-sales and post-sales. So if you think of the point at which a customer signs a contract, that is kind of this, you know, this pivot point where everything prior to that we think of as pre-sales. Everything after that moment they sign a contract is post-sales. Value engineering allows us to take the things that we understand about their business and go really deep into building a roadmap for where their company is going and their business roadmap being supported by a technology roadmap that delivers value alongside the trajectory of the company. So a common problem that businesses will encounter is, is that They will have vendors trying to sell them different solutions across different places inside of their business. They'll end up with 5 to 10 different product offerings that are not integrated in from different software vendors in procurement, inventory management, order management, finance. What we look at in the value engineering exercise is how do we weave all these concepts together and help chart a course for their company and where they're wanting to go as a technology partner and the value that our platform can deliver and the value that our partners that we work with, that are other software companies, can deliver. A great example of this is that we don't do spend and expense. We don't work on spend management. We work very closely with a couple of pretty large companies like Ramp and Brex to help deliver their spend and expense management products. That's an example where we would go into a business and they'd say, well, we have these problems related to spend and expense, and we're not going to go in and try and say use DaaS for this. Um, as people say, you know, if, if you're a hammer, everything looks like a nail. I think value engineering is about understanding which things are screws and which things are nails and which things are staples and figuring out how to piece together and assemble the, you know, the furniture of the company over the, you know, over its coming years through our own solution and through our partner solutions.

It's creating values for your customers, right? So you are a partner, basically you're not just selling them, you're also partnering with them to help them create values for their customers.

Yeah, exactly. And that's the, that's the whole, you know, the, the kind of the premise around value engineering is that it's actually a roadmap and strategy exercise that translates into technical and tactical execution. How do we put the pieces together to take them where they want to go?

Is this similar to like in the software engineer world, we have the forward deployment engineers?

Yeah, I think forward deployed engineering as a concept has become extremely popular lately.

Yeah.

And I think a lot of times it's a code word for, we will go in and do unscalable things to try to hack our way into high-dollar contract values and deliver technology to our customers in whatever shape they need. I think that we can be a little more intellectually honest about what the point of this is, is that our goal with value engineering is to deeply understand our customers and what they need. The second part of it is to then map our solution over that space and then understand where the gaps are. And those gaps we can fill in with their existing systems and we can fill in with partner systems. And then we can work with them to figure out which pieces of this can we help chart for them and which pieces do they need to engage with other people. It's less of a, you know, I would describe as the scrappiness of forward deployed engineering and a bit more of good old-fashioned professional services.

Do you have a software to consulting ratio?

When you say software to consulting ratio, what do you mean by that?

Like you have a platform, right? DOTS is a platform, and then your client can be using the platform, but you custom made them, right? Made the platform to tailor to what they need and create value for them. So, that piece of the work I'm reading, I'm understanding that as the value engineering.

Value engineering is actually less about building the thing versus charting the course for them and helping them build the map to where they need to go. The actual implementation that that translates over to, it looks like standard software engineering on top of our existing platform. And that standard software engineering, just like regular software engineering, is based on this idea of taking templated systems and then integrating them. And so a lot of the stuff that we're able to do for customers are things that are off the shelf and don't require customization. The stuff that does require customization, we need to think really carefully before we do it. Because you enter into a regime where you are going to deviate from either a leading practice or a best practice in favor of something that you do for your business that's unique for your business. And what we have to work through with all of our customers as a part of the value engineering exercise is what do we need to do that's unique? What is considered best practice? How do we merge the two together in a way that allows us to not break the system, not break our forward compatibility, and then also not break our process and what makes us strategic, what strategic benefit we see from it. And that, that's the whole premise and point of the value engineering exercises. We don't want to force them into a shape, but we do, if they're doing incorrect things and they're doing things that aren't ergonomic, we want to help them sit up straighter.

Who needs an ERP system? What kind of companies and what, at what stage?

So I think most businesses that are looking at utilizing systems like this are focusing on complexity. So businesses that are trying to say they have a very simple thing and they want to automate it in entirety, that's not really what we focus on. What we focus much more commonly on are businesses where you have to scale people through the company in order for the business to grow. And It's less so about expanding the leverage of like one individual person so that, you know, a dropshipper can run their business in an entirely autonomous manner. And it's more like we have this, you know, business that's been around for 20 years. We have all these legacy systems, we have 7 sales channels, and we have all these different warehouses, and we have 3 different product lines. We acquired a company. We like really messy stuff. And because the primary rationale for this is that messy stuff and the untangling of that Is not gonna happen on its own. And you can't iteratively work your way to the answer by adding small 5 to 10% optimizations through one Zapier workflow here, or an Airtable setup over there, or maybe even like a Vibe-coded app over, you know, in another place. Instead, it actually requires a strategic thought and weaving through the entire lifecycle of the company and a first principles reframing. And that's what we've designed the product to be, you know, fantastic at is helping these businesses transform themselves in a fundamental manner. So we really focus on those types of companies that have that complexity. Industry-wise, it's physical operations companies. Physical operations companies tend to be the messiest because they're interacting with the real world, and the real world is much messier than what lives behind, you know, our screens and servers and databases. And so the places where the real world has to translate over into an information model, Um, you know, any kind of physical operations companies managing sales channels and a product catalog and procurement and inventory. Those are all places that are really fantastic for us.

So the, the company, the physical product world of the companies like Whole Foods, a grocery store.

Yeah. So grocery stores or, you know, retailers in general are a really good example. Obviously you look at a business like Whole Foods, they're owned by Amazon and they have an entire massive tech stack that they've built for themselves. So you have, we also have to think about, you know, generally which companies are best served through outside parties versus companies that build stuff themselves. Another good example of this is a company like Tesla. Tesla has built all of their own systems in-house. You look at a business like Apple, Apple has not done that. Apple actually runs on SAP. And so companies have like, especially at the enterprise scale, really large organizations, they develop a strategy for themselves. And some of it, some organizations lean towards building things, some lean towards buying things, some do a mix where they build where it makes sense and then they buy when they don't get any value out of building it themselves. Um, and so in, in the enterprise, it's very much a kind of a stratified mix. In mid-market, pretty much everyone is buying because they don't have the scale to be able to justify, uh, the return on an investment from building it themselves. On the very low end of the market, a lot of times people are using the standard off-the-shelf productivity suite. They're doing things in Google Sheets, they're doing it in Excel, Maybe they're using a consumer-grade productivity tool like Airtable or Notion or something. Um, and so we see those examples a lot, but mid-market is a lot of where our customer base is because they need to buy solutions and they have not achieved the scale yet where they can justify building things themselves.

And they don't want to use maybe SAP or the bigger incumbent solutions?

Yeah, they typically don't use large incumbents because of the time to value. So the mid-market companies are growing and changing so quickly that the 12-month implementation lifecycle that they would go through, or the 24-month implementation lifecycle of one of those large Oracle or SAP-scale product suites, their business will be fundamentally different by the time it's done.

What's your implementation cycle?

Usually we take about 3 to 4 months.

One other objection I can think of from a potential mid-market customer could be like, I already have a bunch of tools I'm using, right? Like, how do you, how do you convince them?

Yeah. So. Thinking about specifically the reframing of the consolidation of their tech stack, I think typically that's not the objection. You know, if someone's coming to us and I think at a point in which someone is objecting, let's say in a sales cycle, if they're saying we actually don't think it's possible to consolidate down tools, then, you know, my kind of answer for them is, is like, well, then you're probably going to stick your business at the current size it's at. Because either you will continue to grow in the tools that you have, or you'll consolidate them. And you're probably not gonna be able to scale the business unless you believe that you can, you know, reduce the entropy of that problem. Uh, and so I think it's one of those things where it's like, that's typically not the objection we get in a sales cycle. We get that objection much earlier on when people are getting to know us and they'll say, do I really need another tool? And then the, you know, a lot of times the discussion that comes from that is that We actually help them compress down the things that are redundant and semantically merge a lot of systems. Instead of having a procurement thing over here and an inventory thing over here and an order thing over here that are not connected, they have one system that's all connected. And I think logically people, like a lot of times they'll say, yeah, that sounds great. That's a great concept, but like, does it actually work? Much more common the objection is, does it actually work? And that's a much easier thing to demonstrate.

How do you prove that?

People want 2 forms of proof. They want social proof. They don't want to be the guinea pig, and they want to see the thing for themselves. And so the combination of those 2 things is really powerful when we can show them that companies that are much bigger than they are, that are much more complex than they are, are using our product to reduce the complexity of their organization and to operate at scale. That helps a lot. The other thing is, is just showing them something that looks and feels like what they need and modeling it around their company. So even in, as I talked about in the, we talked about in the beginning, the value engineering exercise, it's getting to deeply understand their business and show them that we can model the applications around what they actually do versus saying, oh, well, you're a, you know, you sell textbooks and well, here's a demo environment for a company that sells toothbrushes. They're like, well, our businesses are very different. Why are you showing me that? Instead, we can actually build our demo environments around what their company does. And it really helps articulate the value very clearly. And that's part of the, you know, component of the value engineering exercise.

How long does it take you, take your team to build a demo for a client?

That's a good question. I think it probably takes a couple hours.

That's fast. 3 hours versus 3 months.

In a demo environment, you do not need completeness and correctness. You need to show the rough concept of an idea. And a lot of times people are very good at filling that last 15% in with their brain. You know, it's like you've seen those studies of that you can kind of like leave a sentence partially uncompleted and people can still read it, right? Or you mix up all the words and people still read and understand what's going on. It's very much the same when they see these systems. They're like, okay, yeah, like I actually get the idea of this now because you showed me one concept and how it was malleable and how it was built around what we need. I get how we can do that now for everything that we talked about. You don't have to prove it to me 10 times. You proved this one equation to me 10 over here. I get the idea. But in implementation, you have to do all of them still, right? It's very much like doing your homework. You do one example problem with the teacher in class and you say, hey, look, this is great. I understand how to solve f of x equals x squared. And they're like, okay, cool. Now here's 40 homework questions. You have to go do all of them. And we're like, ah, okay, here's the work, right? And so that's where we accelerate a lot of that through the, you know, through basically the use cases of AI being able to configure the product. But human beings still need to make a lot of decisions. And we as an organization help our customers move through that lifecycle in the implementation process. But getting organizations to decide how they want to do things and to help them understand themselves is a very difficult path. A lot of the implementation time, that 3 to 4 months, it's not because it takes time for us to configure the product. It's the time in between that it helps, that it takes for us to understand their organization deeply enough to configure the product. That's the hard part.

You talk about like this concept of AI native a lot, and this is also on your website as well. What, what do you, what does AI native actually mean to you?

I think there's a really simple explanation for this, which is, um, we, we have these language models and the way that we think about intelligence is that what does it mean to actually know and to understand something? Having a system that in its own self knows and understands something is what AI native means. So a person who, you know, says, I speak Chinese or I speak Spanish or I speak Korean, uh, and then you go, oh, great. I would, you know, I, I speak Spanish. I'll have a conversation with you. You start talking to them and they pull out their phone and they start Google translating. And you're like, wait, wait, wait, what are you doing? You're not speaking to me. And they're like, oh yeah, you know, but, but I'm fluent. I'm, I'm Spanish native, right? They're, they're asking, they're outsourcing the intelligence to something else. Now, it doesn't mean that you need to be the one running the model and that it's your models and your weights and your whatever. What it actually means is that the context of the intelligence is actually something inside of your system. And it's not something you have to reach outward. And say, I'm doing this translation back and forth between what we know and what they know, and we, we merge them together. The way that we approach this is that you actually have to bring the application and the intelligence into one framework so that intelligence can be surfaced in every single place inside of the application. Not just, I'm in a chatbot and I ask it a question and it'll pull answers out for me. Instead, it's that I can point the intelligence at any part of our system. And so what this looks like in practice for a lot of our business is that our intelligence is pointed at our conversations with our customers. It's pulling from our Slack conversations with them. It pulls it at our Salesforce. It pulls it from all the different surfaces where we interact with our customers. It also pulls it all from the internet so that when our customers ask questions about something that's happening out in the world that might be impacting their business, it's actually going to go on and pull all that information in as well. That's like the pulling intelligence in. Then there's the, how do I direct intelligence out? Just like a person. I can go pick up new objects and go learn about how they work. Our product can actually inspect and scrutinize itself. So a lot of times, you'll try this in ChatGPT, you'll ask it questions. Hey, how are you? How do you work? Tell me about how your implementation functions. What model are you running? We're able to do the same thing with DaaS, which is that it is aware of its own existence. So when I asked DaaS, hey, how do our sales orders get processed? Explain to me how new sales orders come in from every one of our channels. Create an, you know, create a representation for me. And then how would you improve this? And then, okay, now that you've given me these ways that you would improve it, go make those improvements. That's AI native, as opposed to, sorry, I can't do that. You're going to have to go into the GUI and click these boxes and configure it yourself, right? Which is where a lot of products are today. So I think that's kind of our view on this is that the application and its lifecycle and the intelligence all are fused into one.

Is that, is that context, in a sense, context engineering? Because you give access to all the relevant context for a query or for a task that's possible, right? Is that, is that some, some sort of context engineering?

One half, maybe one third of the system. The other third is how you, how you chemically bind intelligence into the substrate. Instead of making it so that you have to reach out and then take all that context and kind of put it into the right ingredients and then give it to the AI model and then pull the intelligent— pull its responses back in and then figure out what to do with them. The distinction is very much related to what I was describing, which is when you open up Claude Code or you open up Codex or you're in your terminal doing something, it really does feel like you can go do anything. Now, if I go open ChatGPT in my browser, In, you know, in the browser, and I ask it to do the same things that I go ask it to do, Codex to do in my terminal, I have a much smaller subset of options. There's a limit. There's a— you're reducing down what is possible. And the same is absolutely true when you go into any AI-native product and you, you know, you're taking the intelligence and you're scoping down what it's able to work on, especially when you're scoping down what it's able to work on. That is directed at its own implementation. A great example of this is if you were to go into, let's say, you know, I'll pick on Salesforce. If you pick, you know, if you go into Salesforce and you try using their AI agent product to actually start changing the implementation of Salesforce itself, it's not exactly the most ergonomic to do that. It's not going to be able to do a lot of things you want it to do. Now, if I go into Claude Code and I ask Claude Code to say, Hey, go in and update how you were implemented for me. Go build your skills, go run yourself in a loop, go take all these wide actions so that you can do things on my behalf. It's going to absolutely be able to do all that. And if it says, I can't do it, but I'm going to go build you an application that can, it will. That's the big distinction is, is that you have way more agency. You know, we call them agents. It's like AI native is actually not the interesting thing. It's that your software needs to be agentic. And it's not that agentic means that it has agents. It means that it has agency, is that it can go do things for you. So context engineering is one half of it. It's giving the information of what it should go and operate on. The other half of it is that you actually need to give it agency to be able to operate in the world.

Is it like, like a README file, like metadata? So, so that the agent will know about how the software is built?

Yeah. So it is not a README and it is not the codebase. It's something in between. The way to think about it is that We actually store our codebase in a configuration that lives in the application layer. So obviously it's stored in a database, but functionally the way to think about it is there's an intermediate representation. Just like your codebase is stored, the source of truth for your codebase is a file, but it runs through a compiler and gets converted into an AST, gets converted into this tree-like structure. We basically build these tree-like structures and we store those. And Software is really, really good at reasoning about those. And it's not going to actually have to read a bunch of code files from our codebase. And it's not going and reading a markdown, which is inherently unstructured. It's actually reasoning on top of a structured system, which has a graph. It's graph-like in nature. It's halfway between reading a codebase and reading a markdown. You're actually reading a graph-like intermediate representation.

And that representation is talking about how the software is built. So it has all the elements, but not the actual code.

Yes. It is the, the way to think about this is that it is the projection of, you know, the system that they're running in is a projection of this representation. And our codebase on our side is what that projection runs on.

What's the benefit?

The benefit is that you give the system the ability to introspect about itself. And so, you know, if you The alternative is that you hardcode the data model and you hardcode the business logic. So that's like on kind of one extreme in terms of it being static. And that's exactly why, like, I would encourage anyone to go into, you know, any product that they— that any product that they're using that says it's AI native and ask it about its own implementation, ask it how it works. And it will maybe pull up for you a documentation page. That's like the other option here is you either read the codebase or you read documentation. Documentation is always a stale representation of what is actually in place. You have created 2 sources of truth. The codebase is actually what it is. And then the documentation is a human being going in, maybe hopefully an agent helping the human being and saying, I'm going to go update this and kind of tell you a rough description. I'm going to paraphrase and tell you what's going on. What we're doing is we're saying, we don't want you to read the whole codebase because we want to be able to change the codebase. We actually want you to, to read an intermediate representation of the codebase that is structured like a codebase, but is more readable and is composable. And so it's a halfway point between the two that balances the trade-offs effectively, which is our point of view.

Who writes that file?

So, the combination of our team builds those and our customers.

Okay. So, it has knowledge about the software and also the business logic as well.

Right. It is the business logic. So it is the schema, it's the business logic, and it's the interfaces. And if we think about, like, I think generally the way that computers work, you kind of, that's kind of all you get. You basically get how is the data structured and what data is in there? You get business logic and functions and the verbs of the system. And then you get, how do I visualize and represent these? And then, you know, model-view-controller, you know, whatever you want to describe is there's kind of all these paradigms for computing, but it's basically— Nouns, verbs, and adjectives.

Is it for the engineers or it's for the product or?

The benefit of this is that it allows the model, the application and its runtime to be fused together. Sorry, the application and its lifecycle to be fused together. So the first places that we actually saw this were in programming. And so any software engineer would tell you that if you could only ask Your, let's call the language models generally. If I could only take Cursor, Claude Code, ChatGPT, Codex, whatever, and I could only run them on the logs, that would be much less useful than actually having them be able to access the codebase. A lot of software products today, they only give you access to having the system understand the data that is inside of it, and then the outputs of its, the outputs of these, you know, of its codebase. They don't actually give you the ability to directly scrutinize the codebase and directly mutate the thing's existence. And so this would, you know, without basically without having the application layer control its own lifecycle, you will never have full self-evolving software. And today software engineers have already realized this, that you can point these software systems at themselves. And we're now hearing about all these companies that are building these self-evolving, basically software factories where you feed it specifications, it builds its own features. It implements it, puts it through its own CI/CD, fixes its own bugs. Why has that not happened in our applications? Why are our applications themselves not self-evolving? Human beings are still going and, you know, I go into my Notion and my Notion isn't going and evolving itself. It just, it sits there.

Right.

Why is that? So it's, well, a lot of these, not to pick on Notion specifically, but like a lot of these companies, they have not designed the software itself to be self-evolving. They have designed their own internal development lifecycle to maybe be behave this way, but the applications themselves don't evolve. They are static. And if you fuse these 2 things together, you put the lifecycle of the application and the application inside of the same runtime and substrate, you will get full self-evolving software. And I think a lot of companies are starting to realize this and this will be happening over the next few years.

Yeah. So, so I think that's the key insight that you're, you're sharing here. So that means that your software is self-evolving over time.

Yes.

And, and this self-evolving, meaning that is human in the loop at all, or it just goes down by itself? It knows what bugs, what's the feedback loop comes back and having, having any data or whatever.

If you think about the loop, you need to design the system so that humans don't have to be in the loop. They're just observers. Now I can always think of it like an experiment that's running. I can always sit. there and watch this experiment in this petri dish, and then I can just decide, actually, I want to stop this. I'm going to take it out, right? Or I'm going to go scrape it or do whatever I want to it, and I'm going to change its behavior. But you don't want to force yourself to be in the loop. You want to have the ability to enter the loop at any point as an observer and move from being an observer of the system to being an actor in the system. I think that's where most of these companies will go, is that It's more so that humans have the choice to be able to decide what the loop is, how decisions in the loop are arbitr— arbitrated. And then a lot of times it'll look like setting heuristics, just like a human, you know, humans and organizations would, where you'd say, how do we score the risk of the thing we're about to go do? In our case, it's, let's say, hey, I actually, someone asked the system to fix this behavior. And we noticed that there's a bunch of errors coming through on our wholesale orders channel. Me as DOS, a system recognized this, I see all these Errors coming through. I'm going to make an improvement. I go in and suggest that improvement. I create a branch on myself. I start testing it. It validates and it works, but I'm going to flag this that a human must review it because I'm touching a hot path in the system. We process $1 million of orders every day, and if I break this, I will break our sales flow. So me as the agent recognizes that this is actually a really dangerous part of the system to touch. And I want a human to review it because I have rules that tell me that I need to do that. And so a lot of what the application will turn into is it will turn into a system where you steer and you provide guidelines and heuristics, you provide rules, and then you layer these policies so that a human can comprehend and govern this evolutionary lifecycle. I think a lot about, you know, I think about it a lot like we'll turn into these gardeners of sorts cultivating and letting these systems flourish and grow. But we're not going to be sitting there, you know, so to speak, watching the grass grow.

You have to declare a goal, right? Otherwise they can go rogue.

Yeah, um, you have to give them very clear directives. So the way we kind of think about this is that it's much simpler to set— I think there's actually an interesting paper on this, which is that, um, multi-agent coordination— the smarter that these, these, the base models have gotten, they actually are very good at coordinating themselves. If you give them clear directives that their end result is a specific thing they should go fix, then they will start to assign their own way of working with one another to work towards that goal. But that has to be the feedback loop. And I think, you know, my background is in engineering and electrical engineering and mechanical engineering and control systems and control theory. And it's been really funny watching software engineers like rederive control theory from first principles. And they're like, oh, what if we took the errors and we feed them back in? And we're like, yes, we discovered this 60 years ago, or 200 years ago. There are Russian scientists that figured out stable control systems and robustness and how you can create bounded outputs on unbounded inputs. So there's all these control theory concepts which we're kind of relearning from scratch and applying into agents. There are ways to force outcomes. By creating stable representations through which that you compress everything into what looks like a closed-loop control system. Um, and so a lot of what we're going to, you know, kind of discover as an industry is how do we create policies that govern outputs, govern towards outputs independent of what happens in the middle of the system.

Can we have control on like hallucination? Will hallucination be a problem here?

Well, it depends on, I guess, Hallucination is an interesting word. So I think hallucination only matters on the output itself. So if you bound the output into discrete outputs and it's not a continuous spectrum, then hallucination is actually just— it is a selection error. And then it turns into a very basic probabilistic, like, I picked the wrong thing, or we deviated from our target, and we will get back to that, and then that becomes feedback. Hallucination in the middle is just the AI models trying to figure out the answer. And so this is kind of the point of like the— I think there's like the sandwich theory around the determinism, which is you want specific concrete inputs, specific concrete outputs. The system in the middle, we don't really care what happens. And the thing that you're optimizing for in the middle is This is so interesting.

So you're saying that, uh, it's like a regression model. So instead of having a continuous probability as your output, you actually want more deterministic outputs, like, is this a cat or is this a dog? And then if you make a mistake, then it goes back to your feedback loop and then you can self-evolve to improve it next time.

Right. Yeah, exactly. And like language models are still at the end of it. Like there is discreteness. It's just such large discreteness that it doesn't feel discrete. Discrete, you know what I mean? And so if we reduce that dimensionality down to something that truly does feel discrete, then I think that's how determinism will work. Like, hallucinations only feel like a hallucination because the possible set of outputs is so large that it feels like it's just making things up. It's like, actually, it just picked the wrong set of things on a very large dimensional scale. And so if we reduce that dimensional scale down really low, then it'll feel like actually just, it is a probabilistically wrong selected value of the N possible set of options. And if you break these N possible set of options apart and separate them across the state space of what you're trying to hit as your targets, you've now created a bunch of very finely guided systems where you say, here is my master data management loop, and here are the 5 things that it goes and optimizes for. And I want it to be at this baseline where it's constantly at, you know, 78% or something or whatever, you know, percentage. And it's always trying to tick itself up, up, up, up. And then you have another, you know, um, let's say there's another heuristic which says, in addition to this, I actually want the time to resolution of this to be under a minute or something. And so you start setting these competing optimizations against one another. And I think the system will eventually converge towards governed optimal behavior. And again, this is control theory. Like, this is how controls work. It's like, you know how to build this stuff.

And, uh, if your systems are truly self-evolving, does it mean that it's lower maintenance on your side as the vendor?

Yeah, that's exactly right. So, where we're at with this is we have not tried to remove ourselves from the process yet. It's still really high effort on our side, but that's because we are still building And we are not in a place where we want to stop being involved because the value of us understanding our customers deeply and still building solutions deeper and wider, being able to take all the things that are being built and pulling them back into the system, that's what we're focused on today. Now, I think the way to kind of think about this is just like building anything. You can, at the point in which you start to create leverage, you decide, Do you reinvest and create more leverage, or do you pull back and reap the benefits? We're still in the mode where we're like, okay, go in and create more leverage. There's still a lot more to go here. And so yeah, I think there will be a world and a time period where we say, okay, we've created enough, time to dial it back. But today we're still focusing on how do we take all the things that are being built, synthesize them down into common form factors. You have to understand the verticalized versions of the products for our customers and all the different places where we can apply that.

Do you think you can continue to compress the implementation time, given that you're self-evolving anyway?

You can compress parts of the implementation time, but there, there are like fundamental human, um, I don't want to call them bottlenecks. It's just, there's a sequence, and that sequence is gated on the limits of human coordination and human comprehension. If you take the 5 smartest people in the whole world, And you ask them to schedule some meetings with each other, they're not going to do it that much faster than people who are 2 standard deviations lower IQ. It's like scheduling people and coordinating is difficult. And so if we assume that our agents are 5 times smarter than we are, I don't think they're going to schedule meetings 5 times faster. There's a human coordination problem.

Yeah.

There's, how do we take the time to have a conversation with one another and get on the same page about what we believe one another think? And the, you know, the, the way I think about this is the, the, uh, theory of the mind and the convergence of the theory of the mind for across individuals. It's like, what do I think that Angelina thinks that I think? And like having that for 5 people until we all have the same answer, that takes like 45 minutes on a topic, you know, it'll take time.

Yeah.

And so, okay, we gotta take 45 minutes and do that. Like agents aren't gonna speed that up. Um, and so, you know, they can help us prepare the right information and set the right context and prime and calibrate ourselves and look at the right things and not waste time. But at the end of the day, humans have to develop the trust in what they're doing. They have to align themselves, and then ultimately they have to coordinate. And that will always be a limiting and gating factor in the sequence of all progress.

I'm still intrigued by your middle layer. Last time you mentioned Terraform, Terraform for the engineer side. It's kind of similar, maybe analogy, but they're infrastructure layer.

Yeah, it's, I mean, fundamentally it's a DSL. It's a domain-specific language. That's what we wrote. Yeah, we call it, we call it ZSL. It's like our internal DSL for our system.

Did you say Z? ZSL? Okay. So, so you have your own domain-specific language for it. Are there any, I'm curious, are there any open source or commercial tools that exist already for that?

There are so many different. Different software languages that have been written, it looks like writing a programming language, basically. So the amount, the toolchain that's involved with writing a CFG or like, you know, any kind of context-free grammar and like a tree-sitter and writing, you know, linters. And so like anything that people use to write dev tools is involved in building this. And honestly, one of the most important systems that we leverage for a lot of this is that a lot of our model for what happens after you write the AST, or you write the language, is that it lives inside of a standard Git lifecycle. Git is the most underappreciated creation of the last 50 years. It's, I think, ultimately where a lot of this knowledge will be, the lifecycle of these systems will be managed through that framework. And so, that's a really important component of this, is that it's not just about the DSL itself. It's not just about how you compile it. It's about how you manage the lifecycle of what that thing is.

Is, is this ZSL thing that the declarative layer that you built, could this be something, could it be its own product? Can you sell it?

At the moment, I mean, you know, I guess the way to describe this is like, we are not selling it. The way I look at this is like, no, people don't sell TypeScript. They don't sell Python, you know, like you sell an application that you'll build with that. Now, or you'll sell a framework that sits around it that's managed in some way. It's built for our systems and it doesn't generalize outside of our systems. The reason it doesn't generalize out of our, outside of our systems is cuz we haven't tried to make it do that. There could be benefit in that, in creating a very general purpose business modeling language. So many people have tried doing that. I don't know if it's a good idea. I'm not sure.

The way how you developed your product, how do you think that should inform builders building AI systems? Right.

You know, it's interesting. I think a lot of today's engineers don't think about this, but this is kind of one of my controversial points of view on this. I think that enterprise software builders from the previous generations thought about it. And if you look at, let's call it like the 5 to 10 really great enterprise applications companies. They all think this way. SaaS companies, what's my way? I don't want to be mean or rude, but I think that SaaS is kind of a blip of, you know, an anomaly. It was a lot of poorly built systems and they kind of benefited from this very unique window of time where you could extract a lot of value with stuff that's really, really, really, really simple. And I think that that era is completely gone and over. And if you look at the software systems that were built in the 1960s, '70s, '80s, '90s, pre-SaaS, they are all orders of magnitude more complex, more sophisticated, more, much better engineered.

Yeah.

Like by orders, massive orders of magnitude. And it's because they had to be. SaaS was an embarrassment of riches where we basically could throw, you know, uh, 8 gigabit, you know, 8 gig RAM at a simple CRUD app. Right. And like, you didn't have to care about how any performance of anything worked and you don't have to care about any generalization. Because you made it extremely narrow and extremely thin. And so I think the people who built these legacy systems, they thought about this this way. If you go look at Workday, you go look at PeopleSoft, they were building composable data models and a DSL back in the '80s, '90s, 2000s, early 2000s. Salesforce built the same way. They built this super composable object model metadata programming language. It's really impressive. I think a lot of people who are in kind of our generation will be like, those products suck. And I'm like, yeah, but they're also, there's a reason that they're so composable and that they're in every enterprise. It's because they built something extremely powerful and it's really hard to do that.

Though software engineers today are not thinking with that kind of things in mind.

Yeah, they haven't had to. I think the main reason was that they have had to think about different sets of problems. And as a result, the composability, like a good example of this is that Composability in the past, you didn't have, and you couldn't just be like, oh, my schema is whatever, doesn't matter. I'm just going to throw it in a document. Who cares? And it's fast and it'll be super fast and I can search on it and it's consistent. And they did not have all of these tools that made it so that they didn't have to think about the ergonomics and composability of the systems they were working with. And as a result, A lot of vertical SaaS is extremely under-engineered. Great products, very, very, very thin technology, which is why I think, you know, people talk about like the whole SaaSpocalypse. It's like when you have a great product and a super thin technology and there is basically no technical advantage and you've just been like, you know, assembling Legos, then yeah, like you're going to get completely wiped out by technology companies.

So do you think for companies today building, uh, building new products, or let's say if they already have their product built, do you think they should think about rewriting for AI or rewriting with, with this kind of, you know, mindset?

Yeah, 100%. I think that product-based companies that have no technology are going to be completely destroyed. And they have to decide whether they want to extract value for a few more years or if they want to try to rebuild themselves. And if, if you don't want to do one of those 2 things, then the 3rd option is, is you have to build an incredible brand. Like a really amazing brand that people love. And so I think that the real durability that's left in this world is building high-performance, high-quality technology and delivering that as a tool or delivering that through a brand experience. That brand experience is the other thing, which is like, do people love the thing that you've built? Because, and I think people are going to, that bifurcation is the only thing that's going to be left at the end of all this is The brand of the experience of the thing and how much it means to you and performance and systems and quality of the engineering and technology underneath.

So that has nothing to do with the product itself. So, you know, a lot of the problems SaaS products are solving, you don't have any objections about those problems they're trying to solve. You're saying that they could have built a more durable and more, uh, more, I don't know, a higher performing product.

It's less that it's higher performing. It's that there's no, there's nothing that is technically durable about what's been done. And the perfect examples of this are people now going and building these systems instantly using their own agentic coding setup. I mean, like our own internal team, we have built so much stuff internally that are complete whole other, you know, previous SaaS companies' products. And we don't, because we don't need the whole thing. We need like the part of it that matters to us. And so, and it's because that at the end of the day, the thing that they built is no longer technically durable. And it has been, you know, it has completely been wiped out by this new technology. And so a whole class of products have to decide, do they want to focus on being a great brand? Do they focus, want to focus on building great technology? Because building a great product without a great brand or great technology is no longer durable or defensible.

What do you think of as a, as a company, how executives should make decisions on like build versus buy? Like, it sounds like you're building a lot of the tools. You probably don't have to subscribe to any of the SaaS that you used to, to subscribe to.

Well, we do use a lot of SaaS. There's just a, it's, you have to pick which ones you want to build and which ones you want to buy. Like, yeah. Yeah. And any, any, anything that I think it's, I think it's actually useful to try to do it a little bit by hand and then see where the friction is. Like anything where correctness matters a lot, you should probably avoid building yourself. Like we're not gonna go build and vibe code a system for us to run our payroll. That would be really dumb. Like spending expense, managing credit cards for our company, we use Ramp. Ramp is great. It's an amazing product. There is absolutely no reason that anyone should try to vibe code their own spending expense. However, the project management tool that we're using to coordinate some, you know, of the management across our portfolio of work, we had a bunch of weird requirements and it didn't fit nicely into Asana. Or Linear or Canva or, you know, sorry, Notion or Smartsheet. It didn't fit. And like, we're like, okay, cool. Like, let's just make our own thing. And it took us a couple of days and now we have something that is precisely exactly what we need. But it's also one of those examples where like, if a product is slightly wrong and the data is slightly not correct or the experience is not slightly perfect, like, it's okay. You can fix a bug in that. It's not really an issue. And so I think the build versus buy for a lot of executives and a lot of people that I've been talking to is the kind of matrix is like, does it have to be correct? What is the cost of an error? Is it a Waymo? Because if it's a Waymo, like, you know, and the cost of an error is you hit somebody and they die, like, you know, don't try to do that, right? Don't build that yourself. And then the other one is just like, is it even worth building yourself? Like, you know, like, even if the cost of an error is, you know, super low, and, but like, for example, calendar scheduling, like Calendly, It's annoying enough. There's a bunch of integrations. Like, yeah, could you vibe code a Calendly? You could probably vibe code something pretty similar to it, but like, is it worth doing? No, like not really. It's not worth doing. And so, you know, that, that's the way we think about this typically.

So that tells me that maybe not all SaaS products are doomed. There are still some values in some of them.

Well, I think they're not doomed, but I think they will be repriced, which is it like they The price now that they're competing with is not against one another's, the value of like fully loaded engineers to go build the thing. It's that there are models that can produce it at a much lower cost. And as a result, they have to be re-rated down to the now, what is the cost of intelligence per token?

Do you suggest builders to try to build SaaS products or do you feel there are still like white spaces out there for builders?

Yeah. Is there stuff still? There is more to build now than there ever has been in the history of history. Yeah, it's the best time ever to be building stuff. Full stop, period. The, the net— the last best time was like when we discovered the steam engine. Before that was, uh, when we discovered fire. Like those are like the 3 other times that are this interesting in history.

Do you have a vision of what's the ultimate form of software would look like?

Ultimate form? I don't know. I think the form that we're on right now is going to be pretty good, which is Software that is situationally aware of its own existence and its own object and the people who govern it and their objectives. And it will steer itself towards the things that they want. I think that's going to be pretty good.

Is there a really hard moment building DaaS? I mean, this is a cliché question, but I'm curious about your darkest day, if there's one.

Not any one day. I mean, every day is really hard. Every day is also really good. You wake up in the morning and you're like, I'm an idiot. This company's never gonna work. This is terrible. And then in the afternoon you're like, I'm a genius. We're the smartest people that have ever lived. And so I think that's the thing that you have to get used to. And anyone who has worked on their own thing understands this, that it's like, it's not just that it's a roller coaster, it's that it, that every day is a roller coaster. Every week is its own roller coaster. Every month, every year, like the whole thing is constantly bouncing up and down. And so you never really know how to feel about it. And so you have to kind of just remove yourself from that and focus on how do we build great stuff? How do we hire great people? How do we point ourselves in the right direction towards where the world is going? And how do we enjoy this process?

You, you were doing B2B sales, right? How do you think about finding distribution partners or, you know, about maybe customer acquisition channels?

The simple answer is from our side is just you Should have a pretty good idea of what problems you're solving. You don't need to be precise, but you need to be like in the right vicinity and then just go hang out where people who have those problems are. And it sounds kind of dumb, but it's like, you know, if you want to get into— the way I think about this is there's all these pools of pain. Like that's what B2B sales and B2B software really is all about. Really any solving problems for any businesses is like, You were trying to go find all the pain and then you were trying to extract it and make it go away for these people. So if you're going to go and find a bunch of pain, you need to go where the people who you think have all those problems are. And you then figure out, are you exactly correct in your understanding of the symptoms and then therefore the root causes? And then do you have the solution to address those things? So for our customers, we go to the conferences where our customers are actually transacting with one another. We're not going to a conference where people are going to an ERP conference. We're going instead to a food and beverage conference. And you, what's, what was her name? Jane Goodall, the woman who studied the gorillas, right? You go and observe the animals in their natural habitat and you're just like, okay, cool. Like, what do they do? What do they care about? Like, who are they as people? What is their, what is their, how does their world work? And then you're like, okay, food and beverage companies, they work with distributors, they work with retailers, they have suppliers. Here's how this ecosystem interacts. Here's how these parties care about various topics. Here's the thing that's painful. I'm going to ask them a bunch of questions, and now I have a rough understanding of how the pain maps across these businesses as a network. And I'm going to go have this conversation with this, you know, sales leader, and I know that when they talk to me about order management across B2B, retail, wholesale, all this stuff that they're having a hard time understanding which channel's performing best because they don't actually understand the input costs to the products they sell on those channels. Okay, cool. But like, I only figured that out because I went and talked to 7 or 8 different people across this ecosystem. And you put together this composite snapshot and you deeply understand like what matters to them. And then there is no shortcut for that. You cannot cheat. You have to just go do that.

Just go talk to your customers.

You go talk to your customers about their problems. That's all you have to do.

What AI tools do you use for, for yourself day to day?

It's very useful to experiment with them and try different ones. Get a feel for like where kind of things behave, where some stuff's better or some stuff's worse. I'm a big Power Cloud Code user. I think I'm like second or third in our company in terms of usage. And mostly it's synthesizing things and then iterating. The synthesis is only as useful as the Sources that you can point it at to synthesize. And I'm always trying to find through experimentation new workflows for myself. So an example for this is, um, I commute into the office every day and in the morning or when I'm driving home, I'll just talk to ChatGPT in voice mode. And it's actually got a better voice mode than Claude. I'll brain dump a bunch of stuff that's on my mind. And then I'll switch it over to pro mode because the pro mode is smarter than the voice mode. I think the voice mode still uses 4. And then I'll switch it to pro mode on 5.4 and say, Take all the things that we just outlined and give me a very detailed research report on all of these topics. And then I'll take that and then I'll go and copy and paste it over into Claude Code when I get home and say, okay, take all these things and like, let's outline the stuff that we can go work on and precisely what we need to do. And over the course of, you know, taking what would have been a pretty useless car ride of listening to music, instead I have actually prepared a whole evening of work for myself and I've prepared a whole evening of work for Claude. And so Like that was something that I figured out a couple months ago and I do it every day now. And the leverage from that is incredible. So it, I think it's just like part of understanding is like, what are the things that you're doing and how you're spending your time and how you can project and apply leverage through these AI tools for taking action and for synthesis of context, especially for leaders. I think it's really important for them to make sure their organization has a really, I think someone at Zapier talked about this, but making sure the company develops a shared brain or like, you know, kind of a shared memory of, uh, of the existence of itself. We built that internally and it's the single most important thing that we've ever built inside of the company for our own productivity. Like full stop, period. Every company should go build one.

What is the shared memory? What format is it?

It is really, really dumb. It is literally just a big file system that runs in our GCP that stores all the artifacts of everything that we do across the company. And then it's a bunch of software agents that are looking at that file system and they're almost like librarians. They just go and shuffle things around and reindex and it's basically built like a search engine, but it's an agentic search engine that it goes in and kind of reshuffles the search for the company. And there's like, there's whole businesses that sell software like this now, but, um, the one we built, we really built it for ourselves. And anyone at the company can access it. They just type in, they'll say, you know, hey Claude, I want to go do X, Y, and Z. Claude has a bunch of skills that are designed to go operate on this dataset. And this dataset is constantly being re-enriched and rebuilt and, you know, recontextualized. And it pulls from our call notes and our Slack threads and our customer support tickets and our Google Drive and Salesforce. And we don't, we didn't put Notion in because Notion's really messy. And so like, we really curated it. And now anyone in the company can ask really detailed questions and it'll go in and spin up artifacts just like Claude would, but instead it's built on this entire fabric that we've, we've constructed for ourselves.

Is privacy a concern? Like, can I ask, like, what is Wiley doing today?

Well, I mean, that's part of it is like, you have to pick and choose the stuff that you actually care, the organization, the organization should care about being private about. So like, it's not hooked up to anyone's emails, but it is hooked up to everyone's calendars. But that's also because like, as a company, we don't believe in private calendar. Like, everyone should be able to see one another's calendars. The Google Drive, it's not hooked up to your personal Google Drive. It's not hooked up to Your, uh, you know, the files that are only for yourself is hooked up to the company's shared drive. And in the company shared drive, it's shared, everyone can access it. And so the whole kind of idea here is, is like privacy is implemented through the framework of what the system can access. And the system is only designed to access things that are, that are, that force opt-in, as opposed to people aren't going to be able to hook up their own iMessage or their own Slack DMs. It can only access public channels. And so our company directive is, okay, if you're talking about certain topics, like, do not put them in DMs, put them in public channels so that we can all benefit from seeing them. And you're going to benefit from this because then when I ask you what happened with X, Y, and Z, you don't have to go, oh, I was DMing so-and-so. Instead you're like, ah, Tapestry has all of it. Like, just go ask DOSBot and it'll tell you. And so the company benefits from basically this, you know, increased open— increased transparency. But this is a component of culture and training that have to go into it.

Does that change how you build your team?

Yes, 100%. Yeah, totally. Activity, agency, judgment, those are the intensity. Those are the main things that matter now. You don't really have to optimize for academic understanding of systems. Like you were describing, your background's in machine learning. The AI engineers that are working today don't have to know anything about machine learning. And It's what I was describing about the SaaS, how software engineers during the SaaS era, they didn't really have to think that hard about the software they were writing. Certain companies and certain businesses had to think really hard about the features and the product they were building, but not so much the technology. AI engineers today don't have to think about the AI. They think about the systems engineering and they're not thinking about how to build a really good, PCA and regression classifier. They're instead thinking, how do I collect the context and build a system that can go out and take action in the world? And so the same kind of revolution is happening on our side, which is like, we don't have to care as much about an academic understanding of a system. Instead, you have to think about the aggregate behavior of the system and people who are thinking on more of that wavelength and they have the agency and the creativity to go in and drive in this new world of possibilities. That's much more important today than it was in the past.

Well, what about roles and responsibilities? And with respect to hiring, how do you define your roles today?

I think you're still hiring for a lot of the same titles. The question is, is like, you have to evaluate what the person's really good at. And just because they have worked on XYZ system from the past doesn't mean it's super relevant for the things that we're— the problems we're solving. There's an AI engineer that we're hiring right now, and he's worked on self-driving cars and fine-tuning and, you know, AI infrastructure. The main thing that's important about what he's able to do is that he's a systems thinker. He knows and understands how we can build all of the stuff that we need to do to be able to solve what you described as the privacy problems, to solve, you know, the authorization, situational access control. Good example of this. Situational awareness for access control is no longer an AI problem. It is a product problem. Which is a good way of thinking about this, for your point, is like a machine learning engineer probably would be really good at thinking about how to solve this problem, but not necessarily using the tools that they've always used, but extending them into this new regime in this new world. And so it's a lot of the same primitives and concepts, but applied through a new lens. And so an example I think about a lot is the red and green button or the red and green wire example. So someone's like defusing a bomb and you ask the agent, hey, um, am I supposed to cut the red wire or the green wire? And the agent sees that they don't have access to have information about the red wire. It's protected, but it's, uh, you know, it, it's actually the correct one to cut. Do you tell them the answer? Oh, it's like, well, they can't actually know this. Um, cause they're not allowed to see it, but I do know the answer. So I can either tell them you're not allowed to know the answer, you know, or, you know, if by giving you the answer, I would tell, I would be giving you access to private information. Or do you tell them, I'm not even sure what red wire are you talking about? I don't know anything about a red wire. I just know there's a green one. You should cut that, right? And so that's not a machine learning problem. That's a product problem from a systems point of view. And the way that machine learning engineers think about some of these things in terms of progressive disclosure and training, these are concepts that these systems thinkers are really good at applying themselves into using the substrate and framework of their academic background. So a lot of this comes down to How does a person think and what are they good at? And less so, what is the precise work and tactical semantic thing that they're good at? Nowadays, do I care if someone is like, oh, I know PyTorch, or I know how to program CUDA kernels or something? I don't care. AI will be better at writing all that code than you in a year anyways. It doesn't matter.

So how do candidates prove to you that they're hireable?

Well, we have our interview process is not that bizarre. It's pretty normal. I mean, it's a lot of It's a lot of reasoning. It's like, here is a problem, let's work our way through it and tell me what you think. And you're testing for subject matter expertise, you're testing for the rigor and quality of their judgment, you're testing for generative thinking, you're testing for structural data modeling. Can they hold a complex idea in their head? Can they break it down into pieces? Can they reason about each piece and then sequence them? Can they deal with hard invalidations where You're thinking about the invariants of something and then how they conflict. It's all very like, it's a lot of standard software engineering concepts, but I don't actually care about the code. I care about how you think.

If you could recommend a book to maybe yourself, someone like 20 years old, let's say, just graduated and you're kind of lost and you don't know how to read a job description anymore.

I think it's less like a specific book and more like a bigger idea, which is like, I think if someone's like really feeling lost, the big thing to look for is a sense of purpose and inspiration and something that is not ephemeral, but something that's durable. And like, you're not— what is it? What is it? Hemingway, wherever you go there, wherever you are there, you know, wherever you go, there you are, or whatever it is. You can't read a book and like, it's going to change your view on the world. Like, this is not how things work. You have to find, figure out inside yourself, like what the thing you're looking for is. And so for me, there are books that I've read that were really impactful and important, but mostly it was just taking the time to think and develop the conviction about what I wanted to do. And then once you find that, finding the right inputs and ingredients, you know, components that turned it into a fire that you can't, that can't be turned off. And I think most of it's cultivated through action and cultivated through experience and time. Just like, go do things. In the case of reading, it's like, go try to find a handful of books that are really engaging. And if you think something's boring, just stop reading it. You don't have to finish books. For me, there were a handful of books that were very transformative. There's this book called Soft War by by Matthew Simons about Oracle in the early 2000s. It's an incredible book and it was about basically the journey of Oracle from founding and then kind of behind the scenes of the early 2000s Oracle and them making the transition to the internet era. And it was written in the early 2000s. It's amazing how much of what they were seeing then is happening again now. Reading about the history of computing, there's a couple of really great books in this. There's the Walter Isaacson book about it. I think generally I try, I try to recommend like looking at history through this cross-sectional lens of how technology has changed over time. The last couple hundred years is probably the most interesting thing people can do right now because we're at one of those moments of substantial change. And it's really good to contextualize what change looks like. How did the world reorganize itself after the Industrial Revolution? That's the kinds of stuff that I'm thinking a lot about right now.

Is there anything still durable these days? You know, based on chatting with you, keep thinking what's durable, what's left? To be durable.

Yeah. Yeah. I think deeply understanding people and how to solve their problems is still very durable. That'll be durable for a very long time.

I love it. So this human-to-human relationship building and talking to people may be more important than, I don't know, writing code?

Well, definitely more important than writing code. Like, I haven't written code in months. Like, I don't, I don't, I don't look at the code that's being written really. You like, obviously you review it, but You're more so sculpting it now. You're not like, it's not artisanal, you know, and you're not like touching every single line of code. I think it's more now about deeply understanding someone's problems and setting the problem up the right way to solve it. Code has turned into kind of plug and chug, and especially to engineering folks and engineering background. I think I reached a point in school where you kind of realize you're like, all these math problems are kind of boring once you set them up. Like, once you set up the problem, everything after that, it's boring.

I have that same feeling. Everything's like, what's left is labor.

Yeah, exactly. Yeah, the laborious, like, I have to shuffle the equation around and now I have to go solve it. It's like, that's not interesting anymore. What's much more interesting is setting the problem up.

Yeah, 100%. Well, Ali, thank you so much. I think this is such a fun and educational episode. I feel like I learned a lot. About the control theory and how you think about building software and how the insights that you learned from the last generation of builders and insights you're sharing to the, you know, this newer generation where we are all using and being impacted by AI. Especially when you're talking about this self-evolving software, it still sounds to me like science fiction. It's almost like a different species of software.

It is. It's a new speciation. That's very true. I agree. Yeah.

And thank you so much for going deep on the architectures and all your insights with me today.

Of course. It was great. Thank you for the time.