Why AI Agents Hallucinate — and How to Actually Control It

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-developing? I go into my Notion and my Notion isn't evolving itself. It just sits there. If you fuse these two things together, you put the life cycle 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. Human must review it because I'm touching a hot path. We process a million dollars 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 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 that is 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 Wiley Jones. He's the CEO of Doss and his team just raised 55 million. Serious 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 Doss operations cloud is the ERP evolved. What is ARP?

Yeah. So the thing with ARP is that it is a let's describe it as a specific three-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 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, I'm planning resources for the 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 I'm a company my strategy changes over the course of you know 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 and has not been able to live up to in the last few decades.

In your opinion, is the ARP 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.

That's interesting. Is that is that a category that existed before you guys or it's you create? Got it. Later later 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 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 road map 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 that they will have vendors trying to sell them different solutions across different places inside of their business.

They'll end up with five 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 Doss for this." as people say, you know, 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 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 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 is become extremely popular lately. 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 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? Doss 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 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're 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 strategic what strategic benefit we see from it. And that's the whole pre premise and point of the value engineering exercise is 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 a ARP 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 drop shipper can run their business in an entirely autonomous manner. And it's more like we have this cup you know business that's been around for 20 years. We have all these legacy systems. We have seven sales channels and we have all these different warehouses and we have three 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 going to 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 life cycle of the company and the first principles reframing. And that's what we 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, 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 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, 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.

And so 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 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. 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 life cycle that they would go through or the 24-month implementation life cycle 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 four months.

One other objection I can think of from a potential midmarket customer could be like I already have a bunch of tools I'm using, right? Like how do you how do you convey that?

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 are saying we actually don't think it's possible to consolidate down tools then you know my kind of answer for them 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 will consolidate them and you're probably not going to be able to scale the business unless you believe that you can you know reduce the entropy of that problem.

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 and 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 you know 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 two 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 two 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 or using our product to reduce the complexity of their organization and to operate at scale. That helps a lot.

The other thing is just showing them something that looks and feels like what they need and modeling it around their company. So even in as you talked about 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's it probably takes a couple hours.

That's fast. Three hours versus three 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 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 know you prove this one equation to me 10 you know over here I get the idea but in implementation you have to do all of them still right it's you know it's very much like doing your homework you do one example problem with the teacher in class and you say hey look you know 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 we 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 life cycle and the implementation process. But getting organizations to decide how they want to do things and to help them understand themselves is a very difficult.

A lot of the implementation time that three to four 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.

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

It I think there's a really simple explanation for this which is 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 understand something is what AI native means so a person who you know says I speak Chinese or I speak Spanish or I speak Korean and then you go oh great I would you know I speak Spanish I'll have a conversation with you start talking to them and they pull out their phone and they start Google translating and they're like, "Wait, wait, wait. What are you doing? You're not speaking to me." And they're like, "Oh, yeah, you know, 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 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 that 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 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 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 you know 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 know you'll you'll try this in chat 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 Doss which is that it is aware of its own existence so when I ask Doss hey how do 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 can 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 life cycle and the intelligence all are fused into

Is that is that cont 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 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 brow 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 li 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 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 is 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 are 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 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 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 me 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 a readme file like a metadata? 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 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 a 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 them 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 is a graph. It's 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 old element but not the actual code.

Yes, it is 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 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 is a is always a stale representation of what is actually in place. You have created two 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 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 this and 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 life cycle to be fused together. So the first places that we actually saw this were 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 pro 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 on you know without basically without having the application layer control its own life cycle 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. It 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? 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 life cycle to maybe behave this way. But the applications themselves don't evolve.

They are static. And if you fuse these two things together, you put the life cycle 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 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. And this self evolving meaning that is human in a loop at all or it's just goes on 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 gonna take it out, right? And or I'm gonna I'm gonna 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 arbit arbitrated and then a lot of times it'll look like setting heuristics just like a 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 notice that there's a bunch of error is coming through on our wholesale orders channel. Me as Doss, a system, recognize 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 a million dollars 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 be 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 life cycle. 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 go rogue.

Yeah. You have to give them very clear directives. So the way the way we kind of think about this is that it's much simpler to set and I think there's actually an interesting paper on this which is that multi-agent coordination the smarter that these a these the base models have gotten they actually are very good at coordinating themselves. If you give them clear directives that they're end result is a specific thing that 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 re-derive control theory from first principles and they're like oh what if we took the errors and seed them back in. And we're like, "Yes, we discovered this in, you know, like 60 years ago that you or 200 years ago, the Russian scientists that figured out stable control systems and robustness and how you can create bounded outputs on unbounded inputs and you know, so like there's all these these concepts which we're like kind of relearning from scratch and applying into a like 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. And so a lot of what we're going to, you know, kind of discover as a 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 for speed and for cost.

This is so interesting. So you're saying that it's like a regression model. So instead of having a continuous probability as your out 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 you improve it or you know 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 you know what I mean and so if we reduce that dimensionality down to something that trul truly does feel discrete, then I think that's how determinism will work. Like hallucinations only feel like a hallucination because the this 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 five 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 and then you have another, you know, 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 good this stuff

And 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 c 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, you know, I think the way to kind of think about this is like just like 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, you know, reap the benefits? We're still in the mode where we're like, okay, go in and create more leverage. Like, 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, you know, we've created enough time to time to dial it back.

But today it's we're still focusing on how do we take all the things that are being built, synthesize them down into common form factors. Do you 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 part of the implementation time, but there are like fundamental human 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 five 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, you know, two standard deviations lower IQ. It's like scheduling people and coordinating is difficult. And so if we assume that our agents are, you know, five times smarter than we are, like I don't think they're going to schedule meetings five times faster. Like just there's a human coordination problem. There's, you know, 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 you know, the way I think about this is the theory of the mind and the convergence of the theory of the mind across individuals is like what do I think that Angelina thinks that I think and like having that for five people until we all have the same answer. That takes like 45 minutes on a topic. You know, it'll take time. And so, okay, we got to take 45 minutes and do that. Like, agents aren't going to speed that up. 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 an engineer side. It's kind of similar maybe analogy but their infrastructure layer.

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

Did you Did you say ZSL? Okay. So you have your own domain specific language for it.

Yep.

Are there any I'm curious. Are there any open-source or commercial tools that exist already for that?

There are so many different software languages that have been written. It looks like writing a programming language basically. So the amount the tool chain that's involved with writing a CFG 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 a you write the language is that it lives inside of a standard git life cycle. Git is the most underappreciated creation of the last 50 years. It's you know it's I think ultimately where a lot of this knowledge will be you know the life cycle of these systems will be managed through that framework. And so that's 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 life cycle of what that thing 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 because we haven't tried to make it do that. There could be benefit in that and 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 five to 10 really great enterprise applications companies, they all think this way. SaaS companies, what's 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 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 like by orders massive orders of magnitude and it's because they had to SaaS was an embarrassment of riches where we basically could throw, you know, 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 generalizations because you don't, you know, you made it extremely narrow and extremely thin. And so I think the people who built these legacy systems, they thought about 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 they built all, you know, this like 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.

The 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 gonna 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 it's consistent and you know like 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 like a lot of vertical SaaS is extremely underengineered. Great products very very very thin technology which is why I think you know people talk about like the whole SaaS apocalypse. 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 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 this kind of you know mindset even

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 you don't want to do one of those two things, then the third option 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 in that as a tool or delivering that through a through a brand experience. That brand just like do people love the thing because and you know I think people are going to that 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 the problem they're trying to solve. You're saying that they could have built a more durable and more more I don't know higher performing product.

It's less than a higher performing is 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 system instantly using their own agent coding, you know, setup. I mean like our own internal team we have built so much stuff internally that are complete whole other pro you know previous SaaS company's 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 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 that decision.

Yeah. Any any any anything that I think it 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 going to go build and vibe code a system for us to run our payroll. That would be really dumb. Like spend an 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 spend and expense. However, the project management tool that we're using to coordinate some, you know, 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?

You know, 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 don't try to do that, right? Don't build it 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'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 rerated down to the now what is the cost of intelligence per token.

Do you suggest builders to try 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 ne the last best time was like when we discovered the steam engine before that was when we discovered fire. Like those are like the three 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 Doss? Right. This is a cliche question, but I'm curious about your darkest day. If there's a 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 going to 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 the 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 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. 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 are trying to go find all the pain and then you're 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 channels 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 seven or eight different people across this ecosystem and you put together this composite snapshot and you deeply understand like what matters to them. And 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 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 Claude 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. So 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 I commute into the office every day and in the morning or when I'm driving home I will 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 four. And then I'll switch it to pro mode on 5.4 and say take all the things that we just outlined and so 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 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 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 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. There's like there's whole businesses that sell software like this now, but 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 data set. And this data set is constantly being reenriched 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 what is Wiley doing today?

Well, that's part of that 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 you know the files that are only for yourself.

Is hooked up to the company's shared drive and in the company's shared drive it's shared everyone can access it and so the whole kind of idea here 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 optin 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 cuz 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 Dossbot and it'll tell you and so the company benefits from basically just you know increased openc increase transparency but this is a component of like culture and training that have to go into it.

Does that change how you build your team?

Yes, 100%. Yeah, totally. Creativity, agency, judgment, those are like the intensity, those are the main things that matter now. You don't really have to optimize for like you know academic like understanding of systems like you were describing you know your backgrounds 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, you know, how software engineers during the SaaS era, like they didn't really have to think that hard about the software they were writing. They, you know, certain companies and certain businesses had to think really hard about the features and the product they were building, but like 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 like, you know, 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 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 sol you know the authorization situational access control. Good example this situational access situational awareness for access control is no longer an AI problem.

It is a product problem which is and a good 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. So it's a lot of the same primitives and concepts but applied through a new lens.

And so example I think about a lot is the you know the red the red and green you know kind of button or the red and green wire example. So someone's like defusing a bomb and you ask the agent hey 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 you know it's actually the correct one to cut. Do you tell them the answer? It's like, well, they can't actually know this because 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 like 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 like 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 like nowadays like do I care if someone is like you know oh I know PyTorch or I know how to you know program CUDA kernels or something like I don't care like AI will be better at writing all that code than you in a year anyways like it doesn't matter

So how do how do candidates prove to you that they're hirable

Well we have our interview process is not that bizarre it's pretty normal I mean it's 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, you know, subject matter expertise. You're testing for the rigor and quality of their judgment. You're testing for generative thinking. You're testing for rigor and data model. Testing for structural data modeling. Like 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 invariance of something and then how they conflict? It's all very like it's a lot of standard software engineering, you know, 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 graduate, 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 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 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 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, 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 of activity just like go do things you know in the case of reading it's like go try to find a handful of books that are really engaging and if you if you think something's boring just stop reading it like you don't have to finish books. For me, there were a handful of books that were very transformative.

There's this book called Softwar 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 it was written in the early 2000s. It's amazing how much of what they were seeing then is, you know, 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 are at one of those moments and 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 will be durable for a very long time.

I love it. So this human-to-human relationship building and talking to people maybe more important than I don't know writing 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 I don't look at the code that's being written really. 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 every single line of code. I think it's it's more now about deeply understanding someone's problems and setting it 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 problem 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 is boring.

I have that same feeling. Every everything is 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, so thank you so much. I think I this is such a fun and you know educational episode. But I feel like I've learned a lot about the control theory and how you think about building software and how the insights that you learn from the last generation builders and the insights you're sharing to the you know this newer generation where we're all using and being impacted by AI and especially when you're talking about this self-evolving software still sounds to me like science fiction. It's almost like a different species of software.

It is. It's a It's a new speciation. That's 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.