Presentation: The Future of Engineering: Mindsets That Matter When Code Isn’t Enough

Ben Greene, founder of Tessi, told an audience that software engineers must adopt startup mindsets to survive the rise of coding agents, which are already enabling companies to retask employees to train agents and then lay off humans. He cited Jevons paradox, arguing that cheaper code production through automation drives even greater demand for software, and stressed Gall's Law: complex systems must evolve from simple working systems, not be built from scratch.

Transcript Ben Greene: I'm now building Tessi. This is what I'd like to talk about more. "The Future of Engineering: Mindsets that Matter When Code isn't Enough." Could have also named it, what startups can teach us about surviving the coding agent apocalypse. Coding agents are exploding. Usage is going up and up. Not just by software engineers, it's also product managers, graphic designers, marketers, salespeople. It's everybody. Everybody can build software now. That's great. Nothing to worry about. Let's face it. It may not be here quite yet, but automation is coming for us. It's already here for a lot of people. Companies are retasking their best employees to spend all their time training agents how to do their jobs, then laying off the humans. How do software engineers bring value when anyone can program computers? If you feel like you have to prove that you deserve to have your job while simultaneously trying to figure out what your job actually is now, welcome to being in a startup. Startups are the perfect example of having to adapt simply because you cannot survive. In many ways, I think what is happening to software engineers in general now is actually very similar to what software engineers have encountered in startups for a while. Luckily, I do think the lessons we've learned from building startups can be applied to building software in the age of coding agents as well. Startup Lesson 1: Always Start Simple We're going to do startup lessons. Startup lesson one, always start simple. There is so much pressure to go straight to the grand vision, to build fast, to scale fast. This pressure has been a universal constant in startups, and it's only getting worse there too. Why? Because code is getting cheaper and cheaper to produce, and that actually increases its demand. Consider the history of automation of software engineering. Kathleen Booth in 1947 designs the first assembly language, taking programming from direct hardware manipulation to symbolic instruction. Grace Hopper in 1952 designs and builds the A-0 compiler, automatically translating mathematical instructions to executable machine code. A bunch of other awesome ways of making software engineering more automated and more efficient over and over again. Stuff we all celebrate. That automation and efficiency has only driven demand in computing infrastructure. This is a logarithmic curve. It would not work otherwise. This phenomenon is called Jevons paradox. Efficiency makes a resource cheaper to use, which causes people to use so much more of it that total consumption rises instead of falls. Now that everyone thinks they can build software, the demand for more and more software, more and more quickly, only rises and becomes more immense. Even though code is cheaper than before, we have to be disciplined. Software engineering is rife with examples of failed attempts to build large systems wholesale. Fred Brooks covers this really well. If you're in a TL;DR phase of life, I'll summarize, "A system that works is invariably built from a smaller system that worked." Coding agents are ratcheting the pressure up to 11 to produce while also being the worst offending enablers imaginable. Do more. Add more. Give me more tokens. Claude Code's always, should I continue? This isn't limited even to software, actually. A system is just a collection of connected pieces that form a whole. Yes, your tech is a system, but so is your product, a system designed to get outcomes for users or customers. So is your business, a system designed to produce more money than it costs to operate. In all these cases, you need to start simple. This idea is actually referred to as Gall's Law. John Gall wasn't a computer guy, he was a pediatrician. It goes like this. "A complex system that works is invariably found to evolve from a simple system that worked. A complex system designed from scratch never works and cannot be patched to make it work. You have to start over with a working simple system." Please, if your business, your product, your tech doesn't produce the results you want when it's small and simple, making it bigger and more complicated won't fix it. Go back, fix it, then add complexity. Startup Lesson 2: Comprehension is Key Lesson number two, comprehension is key. What do I mean by that? Perfection is not attainable. You need to accept that and keep it in mind at all times. Change will be necessary and it will be directed by what really happens when you release to the world. In startups, we like to say that if you're not embarrassed by your product, you shipped too late. That's because a lot of the polish you add is going to get thrown away when you realize your underlying assumptions were wrong to begin with. At InsightSquared, we call this shaving the yak. It's ugly and it smells. Giving it a beard trim won't make a difference. What you've built is going to need to change. In order to change it the right way, you need to understand it. The linchpin of change is truly comprehending what it is you've already built in the first place. We've all been asked for a simple sounding change and had to weather the reactions when we said it would take weeks and not hours that somebody expected. Most of the time in my experience, that's because there's some intricately wired bomb in the code that we don't understand and we are too afraid to change. The only options are to either heroically replace the entire component or cowardly work around it. You usually do the latter. Coding agents make it incredibly easy to create entire codebases that we don't understand from the very first step. It's like hiring a team that copies code off the internet at the speed of sound and always tells you exactly what you want to hear. It terrifies me. Technical debt is necessary. It's not reasonable to build for your 10-year vision when you don't know if the idea is viable at all. You have to know what tradeoffs you're making. Startup Lesson 3: Do Something New Startup lesson number three, do something new. In startups, if you aren't 10 times better than what's out there, you won't get noticed. To be better, you need to do new things that will give you some advantage. Actually, it's really hard when you're good at something to not become blind to better solutions. This is the Einstellung effect coined by psychologist Abraham Luchins and his mathematician wife Edith Hirsch Luchins, a cute couple from Brooklyn. They showed that prior experience actually narrows perception, causing experts to default to familiar patterns even when they're suboptimal. If we get more derivative over time, coding agents are always completely derivative. Just like Kathleen Booth and Grace Hopper, we need to move our discipline forward. When are we adopting proof-carrying code? Who's going to get deterministic concurrency models into production? How will we bring formal validation to software engineering? Coding agents are not going to innovate and drive software engineering or society for that matter forward. That's up to us. Startup Lesson 4: Attack the Hard Bits First Lesson number four, attack the hard bits first. In startups, de-risking is super important. We're already placing a huge bet, so we want to eliminate as many other sources of risk as possible. When you're building new things, you really have no idea how long they're going to take or how effective they're going to be. The mindset I take in new projects and startups, both at the engineering level but also at product and business level, is POC before MVP. If we're going to commit to an approach, let's make sure we know it'll work. Not that it's guaranteed to be the best approach, but at least we know it'll work. When I start a new project, the first thing I do is I make a list of all the functional requirements that I think could possibly come up in the most important ways, and I just try and get them working at some very basic level. Because the more of the unpredictable bits that I can get out of the way, the more predictable the whole rest of it becomes. The more I can have a roadmap and a timeline in all the things my business counterparts are craving all the time. Last month, I was building a proof-of-concept Android app, and this was to deliver a completely offline LLM experience with on-device model and connected on-device vector database for Retrieval-Augmented Generation, RAG. I believed it would be possible, but I wanted to be sure. I wanted to see if I could get it together quickly. I am not actually an Android developer. Of course, I was using a coding agent, in this case, Claude Code, to build it. Claude was absolutely adamant that we build a web-based Llama backed MVP instead. It kept saying nonsense about having a quick demo and conserving tokens, in this case. No, that does nothing for me. I know we can make that. That's there. That's out there. After a while, I actually had to instruct it explicitly to stop suggesting alternative solutions just because they were easier. Coding agents want to avoid the hard bits, but I don't think that's where we need to be going. We still need to do the hard work ourselves, and that's still going to be the most valuable work as well. Startup Lesson 5: Care About Impact Startup lesson number five, care about impact. People need to be more customer focused. Great startup software engineers are the ones who don't see their jobs starting and ending with the code. They don't just solve software problems. They reach deeper to understand customer problems and business problems. They use their understanding of software and technology to figure out solutions that other people aren't thinking of. As software engineers, we are generally the strongest systems thinkers and critical thinkers on the team. Also, the most versed in what technology can do. The great ones learn how to successfully apply those skills way outside the realm of coding, and it can make all the difference in a startup. It's because in a startup, solving the first problem you see is never enough. Solving the surface problem isn't compelling enough to overcome all the barriers in the way of adopting change. To break through, you have to keep digging and digging into people's pain, into their goals, into their hopes and dreams. If you can get that far, and if you can engineer something, then you've got a real opportunity on your hands. A great founder turned investor once asked me when I thought our customers would use our app, and I said, with their coffee. He replied, is that their breakfast coffee, or their after-lunch coffee? He explained that at his previous company, getting to know his customers intimately was the key to creating the experience that fit into their lives at the right moments. He cared about them enough to get to know them, and that caring led to the insights that ultimately resulted in a great exit for him and his company. We need mindsets that drive you to go meet your customer. Mindsets like speed to need, or patience, or waiting. Mindsets that ask you to step into their shoes, to feel what they feel, to empathize. AI agents can't care, but we can. My friend Larry sent me this text. Larry is great. He is the kind of guy who laughs at everybody's jokes. We all love Larry. We do not possibly have enough Larrys in the world. He studied lighting design in college. Now he deploys large-scale digital displays like the massive display at Salesforce Tower, and many of the displays in Times Square. He has no experience creating software at all. Should I feel threatened by Larry? It's not like he's a real engineer or anything. He's not full-stack like me, is he? The reality is, none of us can really call ourselves full-stack anymore. Some might even question whether we're real engineers at all. When I'm vibing away with Claude Code, building an Android app, I barely understand at a component level. I completely don't understand at a code level. I also feel like a cross between a deity and a dumbass. I'm not either of those things. I'm just a software engineer wondering what even is software engineering. Given that I almost double majored in English in college, I had to look it up. I'm really attracted to two particular words on this slide, practical application. To me, that's just creating solutions to real problems. I love solving problems. I have always felt like a problem solver. I think we are problem solvers. We do need to rethink a bit how we go about it. The reality is that for a long time, software engineers have created buffers to keep others at bay. Sliding pizza under the door is a celebrated part of Silicon Valley lore. Reflecting real stories from Microsoft, Netscape, id Software. I think we like the freedom from prying eyes and the time to cope with the recurring dread that we're not as smart as we hope we are and we're going to fail. I think imposter syndrome is something that is actually so baked into us that it comes in the way that we work, in the way that we build our tools, and really all of it. Startup Lesson 6: Get Out of Your Box How do I deal with this? Bonus lesson, get out of your box. We need to grow to be more than just what our traditional idea of a software engineer has been. I saw this post and I really loved it. It's worth a read. Go find it. I'll paraphrase. He lays out the skills that he thinks are becoming critical, like creativity and taste. That's AI augmentation. Learning agility. Systems thinking. Something we're good at. High agency. I would add one more, empathy. Go out into the world. Explore it. Care about it. Find problems that speak to you, that inspire you to make an impact, that you realize you want to build practical solutions for. Because there are a lot of problems out there. We're not going to run out any time soon. Software can help with so many of them. That means that in my view, we all have jobs to do. Engineering changes the world. We're responsible for the change we create. Let's make a good change. Questions and Answers Participant 1: How do you teach empathy? Ben Greene: How do you teach empathy? I'm thinking about my children's classes, because I think they do this. I think they actually very clearly instruct children in empathy in school. I think you do it by practicing it, really. Really, empathy is sympathetic understanding. That you go out and you try to understand what someone else's life is like. What their problems are like. You don't just other them. You try to actually put yourself in those shoes and try and understand what it might feel like, and what the frustration might be. Because at our core, we are all emotional. We're driven by those. Then we put layers of logic and understanding knowledge on top of that. I think you practice it. I think you model it for your children. I think you model it for your employees. I think you model it for your colleagues. You can bake into a culture at a company. Participant 2: One of my very good managers taught me to remember empathy is we judge ourselves by our intentions and others by their actions. Sometimes putting ourselves in their shoes and thinking that their actions may not be based on what their intentions are just helps me reinforce that I should be less judgmental. Just don't be a jerk to others is all. Ben Greene: There's also the fundamental attribution error, which is, when you make a mistake, it's because you're a bad person. When I make a mistake, it's because my environment failed me. We have to break that down. Participant 3: Do you have any concrete examples maybe in the last couple months where your team or anyone who you know is using some of these AI agents in a way that is missing that empathy component and has really derailed projects? Ben Greene: The one answer I would give is, it's similar to if you ever had an experience working with a team that wasn't really part of your company, your business, is that they're not tied into the mission. They do what you ask them to do. That's not their fault. That you give them a spec, you give them a feature request, and they do it. It's just often the wrong thing. Oftentimes, what you actually need is, build me this system that allows me to test whether this is the right thing or whether it's something else. Because of the pressure to go fast, build, it's like the fastest path to where we think we want to go. Then we get there, it's like, wait a second, we did daily standups, two-week sprints, but we actually just did waterfall. We didn't want to be here. Now nobody bothered to really think about the system they were trying to build from a very basic level. They just built a whole bunch of code that does one thing after another. I have run into the exact same problem with Claude Code and Cursor on things as I have with teams that weren't really committed to the mission that I wasn't bringing into the team to the mindset. Aaron : One of the things I find to set software developers at ease that are worried about their job is the fact that, who here hasn't seen a backlog of stuff that's a mile deep that needs to be done that hasn't been done that would be valuable. The way I like to frame it with engineers is saying, there's a lot of our job we used to do that was boring. Writing a GET REST endpoint to bring back data in yet another JSON format isn't particularly interesting and we can't allow AI agents to do that. There is an unlimited almost amount of work that can be done that way. I think just framing the problem the right way, like we get to work on the really interesting algorithm that we didn't get to work on or only got to work on two weeks of the year. Now that's our job. How is that not an awesome outcome that we can actually deliver more value because we're not doing as much boilerplate stuff as we used to, or that we can even contemplate what you were doing, of being able to build an Android. I don't know how to build an Android app but I can sure get the basics pretty easy now, and then I can use the AI to help learn the parts that I don't know, and that's to me a virtuous cycle. You got to frame it the right way. I get from an empathy standpoint why people are worried because this happens to be happening right at a time that we're doing a lot of layoffs. I get why there's anxiety, but there's so much software to be written that isn't the boring stuff we've been writing. Ben Greene: I completely agree with you. I think there is a lot of fear and so I leverage that a little bit in this structure. I don't think that our opportunities are going away at all. I do think that we get to spend more and more time if we do this right on the more interesting problems and the better opportunities. I think what's changed the most is that we have to stop gatekeeping around writing software. That we have to start really just recognizing that, yes, we're going to have a lot of colleagues who can write code, create code, and it's actually not double quote, it's actually the same shit we do. It's just that we know it better, and we can help them and they can help us, and we can go do things. I never have once said I really wish I had the opportunity to go back and do mechanical programming in a big computer. I'm glad I didn't have to do that in college. That's not for me. I think this is awesome. I just think we get to take advantage of the awesomeness when we step back and think a little bit broader about what it is we actually bring in and what things we need to keep in mind. Participant 4: There are a lot of engineers out there that do just label themselves and see themselves as just programmers. Like maybe that's just what they did want to do. They want to take the work, get the ticket done. A question I have is, as a technical leader, how do you empower or change this culture to be one of builders of people who want to be solving problems using AI in these ways, thinking about these business problems like you're talking about, breaking out of the traditional programmer mindset? Ben Greene: One way is to join a startup because no one's got time to figure out exactly what you should do. Startups are fantastic learning opportunities to really broaden your skill set. Not because someone's going to make it easy for you but just because there's just no other choice. From a technical engineering leadership perspective, I think a common pattern I've seen with some engineers and engineers particularly who are trying to get into engineering leadership is a reticence to delegate until they know exactly how something can be done. I think the reason that I've seen is that they feel like if they don't know how to do something and they hand it to somebody else they're setting that person up to fail, and so they want to figure it out completely before they hand it off. You're not growing the other person if that's the way you're doing things. You have to accept that a certain number of efforts are going to fail and that's part of the engineering intervention process. There was a moment at InsightSquared, I was the lead of the platform team that looked over the whole application. We had a couple other teams that did pieces in the middle. It was an interesting architecture. We had a junior engineer who had taken on a major story to build something. Who knows what it was? He told me what his plan was for building it, and I was pretty sure it was wrong. Pretty sure it wasn't going to work. His name is Anthony. I said, "I don't know if this will work. Here's what I think, but you should decide and do it your way and then we'll see." It's a two-week sprint, we'll see what happens. He came back to me two days later and said, "I started working on my way and after two days I realized it's not going to work. Your way makes more sense. I'm doing it your way." It's like, great. Awesome. I never for a moment took away his own motivation, his own search for his own mastery and growth, and we still wound up with a solution. The biggest cherry on top was I was actually right for once. It was a triple win as far as I was concerned. I think we have to give people the room to grow. Paul : Actually continuing on that junior engineer, this talk is great and aimed at a more senior audience that thinks in a system way and a broader scope, but at least from my early experiences some of those simpler problems were a great on-ramp and maybe even some of the really low-level problems like learning assembly back in the day. It was actually really something that informed my understanding of how computers think. What do you think about the impact of these skipping all that stuff or going to this higher level on the pipeline of the new engineers. Ben Greene: I think it goes back to how many of us are really that full stack. We had a class my sophomore year in college called, "Ten Great Theoretical Ideas of Computer Science." It was in many ways a great class, in many ways an awful class. It was great because it was really interesting, and it was awful because that year the professor decided that he only cared to determine who the single smartest student in class was. He made all the assignments and tests so hard just so that it would easily surface the smartest kid, and then that kid became his PhD candidate. That part was less great. One of the things that we did in that class which I still remember was we wrote out a 2-bit processor on paper using NAND gates. Even at the time it was like pieces of paper taped together. I was like, this is cool. I don't understand anymore how that worked, but I know it's possible and that's cool. I think that there's a lot of value in understanding the very basics of how this stuff works but at the same time we are all building on the shoulders of many giants. We have so many levels of compilation and incredible work that happens at each of those that we're barely aware of. We may know at a theoretical level it exists but we don't know what it's doing. I think where a really strong academic background can really be a bonus is when you need to dig deeper to solve a problem that you can't at the surface level, then you have some of those tools to do it. I've built a bookshelf with my dad when I was a kid, but there are still master carpenters out there. They do a much better job at a bookshelf and a lot of other fancier stuff I have no idea how to build. I think it's ok, but we shouldn't not appreciate the fact that there's people out there thinking about how software can solve problems that we're not either thinking about or just not in position to solve. That's really valuable too. It gets around that narrowing problem where your knowledge collapses your thought process of opportunities. People who don't know how programming works sometimes think of really interesting ways for programming to work. The Wright brothers were the same. They were like the least qualified people on earth to start building airplanes. Participant 5: You mentioned during the talk protecting comprehensibility over time. I'm curious maybe what you meant by that, but like how to protect it over time. The first thing that comes to mind for me is documentation, and like, we're not documenting all the time. If we are, no one's reading it. What are the practices in a realm where you are making an Android app? How do you protect comprehensibility over time? Ben Greene: I'll use an inductive proof. At no code, I completely understand it. If I want to understand it when there's lots of code, I need to understand it every time I add code, every iterative step. That's the code review process. I think it really comes down to every time you add change, whether it's code or whether it's infrastructure, that you make sure you understand it. That sounds really obvious and not worth staying on the stage to say it all, except that we're really insecure about how smart we are sometimes. It can be really hard for a software engineer to say, I don't understand this code. I have seen that many times and I have done that. One of the things that I figured out how to do at my previous startup, Outcomes4Me, was to instill the value that if the reader doesn't understand the code easily and that cognitive load isn't low, then it needs to change. It just needs to be rewritten, variables, organization, what have you, until it's just easier to understand. After correctness, think always of the reader. It was more important than almost everything else about the code, was how easy it was to understand, because if someone doesn't understand when they're reviewing it, they won't understand it a month ago when they need to change it and probably the author won't either. I was able to model this successfully by pretending to be really dumb and not understand anyone's code. Then eventually I didn't even have to pretend anymore and it worked out culturally very well until we hit COVID. Then we all went remote. Then, all of a sudden, I couldn't model this behavior in public anymore. It started to regress. I actually had to create a separate engineering Slack channel just for asking questions, and force everyone to ask all their questions in public so that people could see that it was ok to ask questions and not know things in public. Then we started to get back to that culture. Participant 6: The key aspect you talked about is problem solving skills. How do we teach that? I think if you go to engineering schools, go study computer science, programming languages and everything, historically that has been taught, the key skill to learn problem solving has always been there. It had been there in the past. It is still there today. What changes in terms of what students needs to learn, how that learning process needs to evolve? Ben Greene: I think like anything else, whether it's engineering, problem solving, dribbling a basketball, you have to have someone set you up with a challenge of appropriate difficulty for your level and then practice it until you can do it well and easily, and then give yourself the next level. I think there's progression. What you're working towards is that state of flow, where you find that task where for you the difficulty is high but your ability is high and it feels great. Not everyone is going to be great at everything. I have learned having children, they're different. It's fine. I'm not trained to teach people. I feel like I've gotten better at it, both as a parent and as a manager. There's a lot of similarities, oddly enough. Participant 7: Engineering leaders are more and more expected, especially now with automation and AI, to deliver the products that we built prior faster now. How do we balance between delivering a little bit faster but not hindering the product's requirements and the solution as we go forward? Ben Greene: By delivering the prior part faster, you mean like reinventing the wheel but faster than it was invented the first time? Participant 7: Just with maybe different data or different components or different features. Ben Greene: I am so ready to move on from traditional software as a service. I don't know about anybody else how much they felt like they spent building the same things over and over, but we got to get out of that. It's such a waste. There are so many better things we can be doing. As we know what we're doing, some of this is defining the behavior better, looking at patterns. We use tools. We love tools. We need to find platforms. We need to find reasonable tools. Open source is a great way for getting there faster without sacrificing a focus on the end result. In no situation have I ever found that I used an open-source library only to determine that they spent less time thinking about solving that problem than I did. I don't think it's a hard sell to leverage open-source software, and there's a lot of it. There's more and more. It's getting better and better, in a lot of cases. Still a couple cases worse. I think there are ways. I also think that when we can now engage our non-engineer counterparts in the creation process, they can start to feel the difficulty of building something that actually works in all cases. We're so good at seeing the corner cases. A lot of folks that we work with who are not builders don't see them because they don't think that way, and that's ok. When they get to sit in the shoes of building the software, and they show you what they built in Lovable or Replit, you can ask them the corner questions. You can be like, did you think about this? What if the person can't do that? You like this design? What if they're red, green colorblind, 10% of men? Then you get to flip the table a little bit. Participant 8: I'm more curious about during your startup journey, do you have any example when you pivoted your solution on a problem you want to solve? What are the metrics or factors you considered at that time? Ben Greene: Pivoting and metrics. In most cases, you pivot because you haven't found product-market fit. In most cases that you haven't found product-market fit, you haven't gotten to scale. When you haven't gotten to any sort of scale, your metrics don't do much in the way of quantifiable good. Really, you have to go back to much more subjective measures, which is not to say that you can't look at quantifiable measures, and say that this funnel is not working at all. It's very easy to see that this funnel is not working at all, that no one is going through your flow and signing up for your product and using it. It just doesn't really give you any insight on what to change because it's not like you have enough people to split test and do two different variations. Generally, when you're doing that kind of optimization early, they both are bad. By far, the most valuable experience has been taking the idea that we think we have, bringing it to a real person who has that real problem, and watching how spectacularly they fail trying to accomplish the goal that we've given them or the value that they want to get out. Outcomes4Me, just a little context, is a product for cancer patients to understand their disease, to understand the details of the diagnosis, what the clinical guidelines say that their treatment paths are, what their treatment options are. Then also give them tools to find clinical trials, manage their symptoms, track medications, and a bunch of other things. Our first version of the treatment path was completely wrong. It didn't present the information in a way that people could understand. Systematically, from our standpoint, it made perfect sense. From their standpoint, it was not consumable in a way that they were framing it in their minds, and that they needed to interrogate the information and answer questions. Only once we built that first version and put it in front of someone did we realize just how awful it really was. I can't imagine getting the feedback that we actually needed in numbers. Later on the line, we could tell that our marketing approach wasn't working, and we needed better numbers, and that could help. Early days, pivots aren't driven by metrics, really. Participant 9: One of my own personal observations trying to use coding agents, and I'll tie it to how I've seen it play out in our organization as well, is, I don't seem to struggle with the code. If I do something that produces a volume of output, I go back and look at it two, three months later. This is what I wrote. I don't even remember that code anymore. With the organizations now saying, we would like to see 90% of you use agentic AI to do your coding and whatnot, I see this playing out with engineers as well. They produce solutions that they don't understand themselves a couple of months later. What are your thoughts on how we can make the situation better? Because I feel like maybe we will lose some of the edge. Ben Greene: This is the lemming slide. This is like all of us happily jumping off a cliff that we can never get back on. This one scares me. My really pessimistic view is that some companies actually understand the hole they're digging from a comprehension standpoint, and think that they'll ultimately be better off when they have AI that understands all the code and they don't need the people. I don't really think that's going to happen because those companies will not be able to innovate anything, and they'll just be slinging slop. I don't know how to do this. I think what has to happen is the idea that engineering has to happen at a pace where the engineering team can continue to understand how things work, has to pervade the whole organization. I actually was thinking that this is something that investors need to understand too. You know that the companies you invest in are going to have to make changes. You need to understand what happens when you drastically increase the rate of accumulating technical debt, because that's really what this is. We've seen the Twitter, how it was going, I just vibe coded this app. How it's going now, everyone's attacking it. I got to take it down. We've seen those memes. I think people realize, this isn't ready to be deploying production apps. We've seen a bunch of problems that have become public. We'll probably see some companies who go too far down this path and then explode or implode or fall apart, however you want to do it explosively. Then we just need to make really terrible examples of them and scare other people to not make those mistakes again, because at the end, those who do not know history are doomed to repeat it. People are going to keep trying that, unless they're reminded how bad of an idea it is. See more presentations with transcripts