Cutting Edge AI

#5 AI-Written Software: Tyler Dunn (Co-Founder, Continue) on the Future of Coding

Angel Invest Season 1 Episode 5

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 37:40

In this episode of Cutting Edge AI, Jens Lapinski and Robin Harbort speak with Tyler Dunn, Co-Founder of Continue, about how AI is transforming software development.

As AI agents increasingly write code, a new question emerges: who reviews it? Tyler explains why the future of software may involve AI reviewing AI, and why developers may soon stop reading most of the code they ship.

The conversation explores the rise of continuous AI, the need for a mission control layer to govern fleets of coding agents, and how trust, testing, and automation will replace traditional code review.

They also discuss the future of programming languages, agentic development workflows, and why the next generation of developers may think less in code and more in systems.

Topics include:

  • AI agents writing and reviewing code
  • Continuous AI and automated agent checks
  • Mission control for fleets of developer agents
  • The future of programming languages
  • Why developers may stop reading code entirely

This is Cutting Edge AI brought to you by Angel Invest with your hosts Jens Lapinski and Robin Harbort. 

[00:00:17] Robin Harbort: Our guest today is Tyler Dunn, co-founder of Continue AI. What happens if you use different AI tools and agents all writing code? Who reads the code before it gets shipped? That's what Continue AI is automating on their journey to what they call countinous AI. Previously, Ty was an early member of Rasa, a conversational AI platform in the GPT2 era, working together with OpenAI on models like GBT2, 3 and Codex. We talked about AI agents, the future of programming languages, and if this is already the singularity, enjoy this episode of Cutting Edge AI podcast by Angel Invest. Let's go. 

Hello, Ty. Welcome to the Cutting Edge AI podcast. So great to have you here.

[00:01:09] Tyler Dunn: Hi. Thank you for having me. I'm excited.

[00:01:11] Robin Harbort: And also welcome to Jens, my fellow co-host.

[00:01:13] Jens Lapinski: Hey guys. Good to be here.

[00:01:14] Robin Harbort: Yeah. So we have Ty today on the podcast. As I said, really great to have you here. Maybe Ty, for those who don't know you, please could you describe who you are and what have you built so far?

[00:01:29] Tyler Dunn: Uh, I'm Ty or Tyler, one of the co-founders of Continue. Kind of my background actually starts in I guess a long time ago in Detroit but for this conversation the relevant part in Berlin, Germany, actually, where I was the first product manager at a startup called Rasa, and at the time we were building the open- source machine learning agent framework during the GPT2-GPT3 era right I was for those of us have been around in AI for almost a decade or some folks probably maybe even longer, you kind of start to delineate your eras based on what what models were there. 

So during the GPT2, GPT3 era, that was that was my time as the first product manager at Rasa and I was about employee 10 or 15. We grew to 150 while I was there and it was a wild ride. Excel led the series A and Andreessen Horowitz led the series B and we did some really awesome research for example actually in collaboration with OpenAI where we were using GPT 3 as a user simulator. We were fine-tuning it to talk to our supervised machine learning chatbot at the time because you couldn't trust large language models in production. We were taking GPTJ the original open weights AI model and creating synthetic training data that would then be used to power our supervised machine learning models and we were playing with something called codex at the time which if you've recently joined the AI coding wave you're like oh codex how did you all play with that in 2020/2021 like that didn't exist well before it became a whole developer tool product it actually was a model and it was a model that was very similar to GPT3 Da Vinci but it was entirely focused on Python generation. It was the model that would then power the original GitHub copilot completion, the first kind of developer AI developer tool product that most people became familiar with at least at mass scale. It also had an API and so at Rasa what we were doing is we were taking it and we were generating Python SDK code with it. And it was magical then and uh it was barely capable of anything, but it got me thinking, right, and it got my uh now co-founder thinking right um because I was able to get early access to it and begin playing with it and it became clear that these models were going to be general text manipulators, so they were going to help us go from English to code or from code to English or from code to code or from English to English. And if you think a lot about like what white collar work is, it's doing that those transformations. And so to have these models at a minimum to accelerate us if they only got a little bit better or that would maybe take over large chunks of it or in some people's views as I'm sure we'll talk about all of it, right? And so it became clear to me at that point by 2020/2021 that these models were going to fundamentally change how we worked. And we were software engineers, my co-founder and I. And so we started playing with it and the the last side project that we were playing with was kind of building a customizable GitHub co-pilot and uh we started that in in June of 2023 and it's been a little bit over two and a half years and continue kind of has remained in the same mission of let's amplify developers not automate them not in like the very simplistic like oh we need to protect creativity but in the sense that like from a very system design perspective like the best AI systems involve like really tight feedback loops with humans and the best humans today are really using AI as part of their feedback loops. And so the idea of amplifying developers, not automating them is one, let's avoid the identity crisis of, we're not going to be able to do anything in the future. Everything's going to be automated. But also you I think more importantly like just from like a pure like what's going to work really well as an engineer perspective, I think it's it's about making sure that the both the best qualities and capabilities of humans and the best qualities and capabilities of AI models are kind of tightly coupled. So at Continue, we've very much had that kind of be the through-line, but because of how fast things have evolving what that has actually looked like what the interface between AI and humans has looked like from between software developers and and AI has looked like has evolved quite a bit so when we started when when we began working with with Jens and the Angel Invest team and mat over there it was a VS code extension right and then it became clear that it wasn't going to be a single IDE it was nice to no longer like copy paste from chat GBT you could remain VS Code but lots of people use Jet Brains so we had a Jet Brains plugin as well but then it became clear that these models were getting so capable that having it inside like one agent in inside of an IDE next to you wasn't going to be enough. And so that's where the continue open source CLI came out, right? And so we use kind of the learnings of each of the Jet Brains and VS Code extensions to bootstrap the CLI that could run not just I mean one at a time but many. And once you have that kind of parallelization, you start to kind of have that future of agents taking over AI taking over increasing amounts of the software development life cycle. And so what we've built and that we are launching this month is continue mission control, right? Uh where you actually take the open source CLI as the engine and you kind of add the control plane, the governance layer on top of it that you need to be to be confident in um shipping with large amounts of AI involved in the process. So, I'm sure we'll dive into what that means, but I'm super excited to be here on Cutting Edge and and talking about it.


[00:06:20] Jens Lapinski: One thing that I get I gave a talk last year actually on the 1 of April 25, I talked about how like I I thought about the the future of AI in the in the context of an enterprise, and it was just apparent that in enterprise there's going to be a plethora of agents. I mean an almost an uncountable number to a certain extent, and that the agents were going to go literally wild. Right? As you now see when you when you have some fore-eye where they can talk to each other the extent to which that is fake or not. Let's not debate that. But it's just when you see that kind of level of interaction but when you have agents that write code and quite a lot of them and for quite a lot of different with different developers. My thesis was you need sort of mission control. You need something that sits in the center and orchestrates all of that because otherwise you're going to drown in absolute nightmare. And this has turned out to be completely accurate and and let's talk about what does that actually mean? What are the core pain points that you see? And it's not about so much slop and wrong code and things like that, but what are like the that you guys have been working on this for a few years now, but what are the the the two or three things where you say, "Look, those are the things that we needed to fix in order to really get on top of that." How do you think about that?


[00:07:33] Tyler Dunn: Maybe the the two pieces that is just like pure model capabilities, right? Like you have the issue and and in some ways it's still an issue where like if you only have 99% reliability on step one and then step two, you only have 99% reliability and step three, you only have 99%. You multiply those out after even just a short amount of steps and it ends up being zero. 

And so the models would just and they still fall over if you do long enough horizon tasks. The the number of nines is increased. And the number of steps that there that can be done are still there. But it's still the case that right if you put in too much context and there's context rot or if you let these things run for too long they'll very much still go off in the wrong direction. Right? They're really good at predicting the next step. But the problem is if your previous steps were wrong, then the prediction of the what the right next step is going to be is going to be wrong. And so once you make a wrong step, you very much go off in in the wrong direction. There is some capability of the models to to steer back. And so it's it's been mostly like watching kind of us go right from GPT3 to GPT uh 3.5 to Claude 3 like 3.5 to Claude 4.5 and kind of in that progression what we've seen is these models capable of increasingly longer horizon tasks, right? Because they can go for longer amounts of time and complete tasks that involve more steps you end up in a situation where now they're actually capable of automating things where the trade-off between I could have done this manually and let me hand this over to the AI the calculus becomes different and the other on the flip side that we've seen is the developers, right? Like even if we had those capabilities two or three years ago, I don't think they would have been ready, right? Like it takes a lot for people to change their behavior for them to build trust in systems, especially systems that involve something as complex as as these very large language models that have all this engineering and science and research behind them, right? That have different properties than what you're used to when I mean, in some ways back in the day when code was meant to be read and legible. There's a good blog post yesterday from Joe at Heavy called Write Only Code. I've been thinking about it all all evening or all all night, since last night. And so that's on my mind. But the other piece on like the starting point is like yes, I agree that like mission control is definitely where things are heading. A lot of folks have identified that. I

I think the really tricky part right now is like given what I was just talking about like what is the starting point, right? Like if initial adoption of AI like kind of in the inner loop involved a VS code extension where it was really as simple as stop copying and pasting from chat GPT in your in your browser to using it in in VS Code and like that allowed for for Continue and Cursor and GitHub copilot, and all these awesome kind of in interloop tools to emerge. What's the equivalent for mission control? And the what we've discovered after now for almost nine months kind of building mission control and playing around with it and really using it and giving it to users and testing it, is the place it seems to be starting is with what we call agent checks. So we call it continuous AI really to hearken back to continuous integration where you have these automated tests. And so if you're not super familiar, right, when you push up code to GitHub, the CI runs, continuous integration runs, basically, it's just a set of tests that the team have agreed that if all of these tests pass, in addition to human reviewing the code, we can actually merge this. 

It's kind of like automated review almost. And what we're seeing is that in the AI world, something similar is emerging called continuous AI and what we call agent checks where you actually do the same thing you did before, right? You as a team, you collaborate and you write kind of however you want to frame it, agent skills, rules, like whatever basically intent kind of constraints that you that want to to have check for like invariants to make sure that are are met, right? And at the time that you push the code, you actually go and check for those things. So it could be like, oh, does this follow React best practices that Vercel has put out, right? Does this code that's been like pushed, does it have any security issues? Like we have one that's like the anti-slop check, right? It's like, is there any slop in this? And people often will ask, well, I have my Claude.md and my skills and my rules and all of that. Like I I don't need this kind of check at at the at the CI level and and the same could have been true and probably was said at the beginning of CI, right? I could just run my test locally and you can and you should and you should have great things. But what you find is, if you start to use AI enough in your coding process, that you need a way for the team to kind of build trust and collaborate together and you need to be able to basically assume that code that's been pushed up maybe was written manually, maybe it was written with a generic Claude, maybe it was written with Gemini's sidebar inside of Google Chrome, right? Like, you don't know where this code came from. And so you can't assume just because you have a Claude.md and even if you do have the cloud MD like you can't assume that that Claude actually followed it especially when you start to add too many skills and rules and so to get the guarantees you need especially for trust to be built and for you to have confidence and for it to not be like humans have to review every line of code, like I would argue is now in the past, or very quickly is about to become the past. You need automated systems and that's where the first kind of mission control comes in where that first trigger that will cause the agent to run will be the PR open but then longer term I think it goes to what you're talking about Jens where it's okay PR merge, becomes a trigger where if I've updated post hog telemetry I should have an agent that goes and updates the post hog dashboard so my business person who relies on that dashboard is not wondering why it's no longer working right or I don't have to manually do it and then longer run other things in the environment so like sentry alert comes in sneak vulnerability like shown all of those should be triggers to to also kind of automate further and further and I think that's how we get to your future Jens of an enterprise that has tons and tons of agents. But I think for developers, it seems to be starting at the stage of PR open and triggering a check, that will make sure no matter where this code come from, it it fits the standards and tastes of that team and that you can have confidence without having to review every single line of code manually to to ship it.


[00:13:18] Robin Harbort: So is this already AI reviewing AI written code? So are we close to the singularity or because there's a do you have like an AI/not AI which reviews the code and then one rewrites the code or how does this work?


[00:13:34] Jens Lapinski: You know, I I read this article that Joseph from HeavyBit wrote, where you posted the link here, and he he basically talks about write only code, but that's not quite true because obviously the AI reads the code. Yeah. So, it's like what it means is it's the humans no longer read the code and from our perspective like the human perspective, it doesn't actually exist. It's like somewhere in the it's no longer there. It's just a imagination that only the AI as we don't even know what's in it because nobody has read it.


[00:14:09] Tyler Dunn: Exactly.


[00:13:34] Jens Lapinski: So what it means is that it pushes us up one layer of abstraction further away from what's actually happening. So we also invested for example in a completely slight detour but it makes sense in a different company called Daisy Tuner which is uh built an AI compiler. So you can compile any code onto any chip. 

If you think about it if you go from machine code up to you know up to extracted language what you thing is that we've now gone to the level where basically not even there anymore. We're now at the AI interface level and the AI is writing. So it's one level further up at least and then therefore we can't even look at the code anymore. It's literally it's not even that it's so long but it's also going to become it's going to change so fast that we can't even do it anymore. Is that correct?

[00:14:52] Tyler Dunn: Yes. Yes. And to be clear, right, I'm being a little bit provocative in in this conversation. because it's the cutting edge. I'm not sure when this will come out. This might be you I mean exactly true uh when this comes out. This might become 6 months or 12 months, but it's very much where we're heading and where like the pattern we're seeing in the most I mean there's there are companies in San Francisco that are not allowing their engineers to read the code. There are companies that are saying don't read the code. There's increasingly in the behaviors I'm seeing people like shipping 11,000line PRs last week, right? Where it's like there's no way you someone on your team read it. Not that we should be counting code and things like that. There's lots of problems with many of these statements, but I think directionally what you're saying yens makes sense right and is is very close to what I'm talking about right where most of the software history right trust me traceability and this and this really goes to the conversation of like are we heading towards the the singularity in in some ways right but previously if you read the code right you could walk the logic from the leaf to the root you could explain what functions did why you could be responsible for it right like code review at the time wasn't just like QA like quality assurance it was like basically the moral foundation of the profession of software engineers Right? I I read it, therefore I own it. And what we're talking about is that foundation cracking basically, right? 

And so that original contract, that legibility equals trust, Unix philosophy, all of those kind of things, all that assumes we're going to read it. But if we're no longer reading it, right, if the history of software is also like one bottleneck after another being eliminated, I think this is the bottleneck that's being eliminated. And what Joe is talking about, right, is hardware gave way to the cloud and infrastructure developer velocity. And now developer velocity seems to be getting giving way to something else. And so it's not like we're saying that code review is dying or like agents are going to do all of the the code review. It's just the what code review fundamentally is, which is trust and enforcing it is changing. And so I think it's going to look more like the immune system in the future, right? Like all of us trust our immune system. And the reason we trust it is because not because we've read the source, it's because when a pathogen comes in, we respond to it and we trust based on the history of outcomes, right? That like, oh, this works well. And that higher level kind of abstraction is figuring out what are all those ways that you can instrument the system, understand it, build confidence and when things go wrong immediately remediate, right? And so in some ways software becomes more like a living system than what it had been before which was like an encrusted mental model and in the shared minds of of the developers working on that that software.


[00:17:19] Jens Lapinski: If it can no longer see the code effectively, what's the difference between closed source and open source?


[00:17:25] Tyler Dunn: I think yeah, I mean if if some of the early signs of where open source is going right now are remain to be true. Like open source will be like English repos almost, right? There's some folks that are now no longer accepting code contributions because they know people just are prompting AI to do this PR. So instead they're accepting just the English prompt. So they're like, we want to know what prompt you're going to give the AI and we'll just run it ourselves. We don't need you to do that, right? And so it becomes effectively like there's code underneath but effectively almost like an English repo that people can contribute to. And so the difference becomes if if you follow this metaphor, right? Like open source is where anyone can come along and give you the English for your agents to run or they can have their agents create English that that is given or or not, right? And so closed source would be a situation where only a specified set of people are allowed to be involved in that process.

[00:18:13] Robin Harbort: Yeah. I just wanted to ask you what's the coding language of the future and why it's English, but you basically answered this yourself.

[00:18:20] Tyler Dunn: I also yeah, I mean like there still be like coding languages under the hood, right? And I I wrote this where I got interviewed by this journalist for lead dev about this like are there going to be more or less niche like programming languages? future more or less niche, and my answer really comes down to like it really comes down to like who's willing and I guess really not anymore like who's willing to use agents that will like decide right how much code there is like right now the reason that like Typescript and Python and these languages are AI so good is because there was so much of this on the internet right and the people working on it they're optimizing the post training systems are optimizing for those languages and so it's like whichever communities embrace AI the most right whichever opensource objects embrace AI the most. They'll be the ones in the training data like their amount of data in the training data sets. They're kind of like their representation and the distribution of the post-training that these labs are doing will determine like whether they're kind of that underlying thing. But you're exactly right that like a lot of folks won't think about it. 

I think this generation of developers will just because we understand code like in the same way that like when compilers came about and my generation stopped didn't really think in assembly. It was like one class we took so we understand the fundamentals of it but like I didn't think in assembly because I didn't spend years or decades thinking in assembly and then high level programming languages came out and then I started using those but I still kind of thought in assembly. I think today's developers will still think in code because that's what their a lot of their training is and there's a lot of value on that underlying thing. I think the next generation of developers will similar to what my generation did of just assuming that okay I understand the principles of assembly I don't need to like think in it. I think the the next folks right will do that. But this current generation is kind of that in between where we remember the before times and we're about to experience the after times and that will give us in some ways a unique perspective and a unique ability that say the next generation or many folks in the next generation won't have. Um but right now we're trying to figure out like how do we build these continuous systems, these automated workflows, behavioral envelopes that give us guarantees, glue between trusted tools that basically allow us to be responsible rather than reckless, right? And if we can set those up and we can teach the next generation to kind of manage and build these continuous systems, these fleets of AI agents. They might not understand the underlying code in the same way we did or won't often, right, unless they go deeper into the problem. But yeah, that's that's kind of where my head is at at the moment.

[00:20:43] Robin Harbort: It's like so interesting because right now we can look back, for example, in banking and we see like the core system of those enterprises and we don't really understand anymore and we just built layers on top and now this kind of repeats. If we look in the future, we might look back at written code and we will not understand it. But you just mentioned one really interesting term. You said agent fleets. And in the preparation for this podcast, I came across several of those terms. So we we got vibe coding, we got agent fleets, asynchronous agent, and agent swaps. Could you could you please explain to me like what are the differences of those briefly, and where are we at right now?

[00:21:25] Tyler Dunn: Yeah, it's funny. I actually used the agent fleets word because it was in the prep. I hadn't read it. I actually asked Claude to explain the I'm not going to just repeat what I read on Claude because these words don't mean anything, right? Well, they do, right? But basically, everyone's trying to like figure out how to like talk about, maybe like the way to put it is it's actually the the good thing that has happened that for both I mean maybe idealism but then also pragmatism is that it seems like we're not going to end up with one model to rule them all, right? And one agent to rule them all. That there's a lot of I guess from a performance perspective first. So that's like the pragmatic reason it's happening that almost taking the Unix philosophy of like specific tools and applying that same idea to agents where like if you look at Gastown if you all are familiar with that like, there's like the mayor who has a specific kind of role and does a specific thing and, then there's all these other kind of types of of more specific agents. I think that is going to remain to be true just because like you actually get the best performance by being, like your job is to audit the security, like your job is to make the plan, right like I don't know exactly what and that's why people are trying like swarms and fleets and and vibe coding and all these kind of different ways of framing it, cuz Now we're trying to figure out like how do we think about this like what are the the the fundamental building blocks? Right? which ones are when you say something like like swarms and fleets right maybe the fundamental building block is agent there right and that's the thing that matters and then depending on the situation sometimes it might be a swarm sometimes it might be a fleet, not that I know what the difference of those are but you end up in a in a situation right where you you still need small composable tools that do things well those are the agents that we're talking about and then the composition is or orchestration, right? And there's behavioral contracts um rather than kind of traditional code review, right? That gives you the confidence that like, okay, this factory or this fleet or however like whatever metaphors you want to use, remains to be true. And so, and like we were talking about, I don't think you I think the thing that's really changing, it doesn't really matter what those metaphors really are or what exactly those terms are, is that like we're not bottoming out into code that humans are going to read anymore or we're about to, right? Instead, the tree is going to be deeper than any human walks is capable of walking. They don't have enough time to do it. The modules can be opaque. You don't even necessarily have to have the the implementation, but the interfaces are going to be what really matter, right? They're going to be really the last legible layer. And then the workflows that connect them is is where the engineering judgment is going to live. And so, I don't know exactly what those terms mean. I I recommend folks paste them into Claude and ask and I'm sure it will have an opinion. But I think the underlying point is just that those are metaphors, right, that are basically a people's attempts today to describe this future, where, that we don't bottom out into code, right? In the same way that we we don't bottom out into some source implementation of our immune system. We learn to trust it and we basically have made sure that it and like in the case of software of the future of software that that we maintain the integrity of the system as a living system.


[00:24:18] Robin Harbort: So maybe to rephrase this question, how does the work of a really really efficient and good developer looks like right now? Because you mentioned people in San Francisco go pushing thousands of lines of code. Are those really really productive developers? Are they using five different AI coding tools in parallel? Do they copy and paste a lot? So, do you have like some experience also? Maybe from your coding experience, how do those people develop at the moment?


[00:24:49] Tyler Dunn: I think there's just such a large variation. I think there's a large variation because the best folks aren't trying to be productive. Maybe this isn't the best thing to say in a in a business context, but they're playing right now, right? And reason play is so important is because like if you try and optimize right now for for being productive, it's you're going to end up in a local maximum, right? You're going to basically build a lot of abstractions as we've seen this over the last three years especially like that just won't hold as the models get better as people learn to use them. And so you're better off just kind of constantly trying and playing and doing different things. 

What if we didn't read the code, right? Like what if we set up continuous AI agent checks? Like what if we made a bunch of skills? Like what if we didn't care about our Claude.md? What if we had Claude manage our Claude.md? right? Like what if I mean we use this programming language versus the other. But the important thing is kind of that openness. It's it's something that we've we've talked about in over the course of the history of Continue and I think it's still true is it's like people always ask me is it like the senior engineers or the junior engineers who are better at coding with AI, and it's like that's actually not the dimension I think that I've seen. It's really the dimension of openness and you can be a senior engineer and very open to trying new things, and doing new things, and changing your behavior and ideas and ways of thinking about the world and beliefs, right? And you can be a junior person and also have that. And so in some cases, junior folks are really good building with AI. In some cases, senior folks are building with AI, but really that trait of openness tends to be, I think, more correlated with like how well you're using AI. And so I don't have a direct answer because once again, when this podcast comes out, I would say that if I could somehow distill today's people into a particular way of doing things that it wouldn't be relevant anymore. And I also just don't think you can, at least the best people, or people who are just playing and trying things, right? But I think that that we're starting like write only code or some of the things that that Jens mentioned, right? We're starting to hopefully have some amount of fundamentals and principles that that play is creating and then eventually that play will turn into like okay, it's solidified. The model capabilities aren't increasing that much anymore, right? Or the ways that they are predictable and so as a result we can actually have some amount of a foundation here and then that can be used to make us more productive and then we can teach other people, right? So like the agile system is coming but we're kind of the right before you can actually define what agile software development is where we're at the stage of like what if we just shipped really fast and talked to users and shipped again right and so we're kind of at that stage and the exact right ways to go about it and principles and something that I can easily package I just don't think exists yet because we haven't figured it out quite yet.


[00:27:19] Jens Lapinski: One of the things that we have discussed here actually we wrote a report about it last year right, I mean, Robin did, but anyway where we said that intelligence is partially a product of just of the sheer size of the number of in our case neurons in our brain or something like you know basically if you get to a certain size that there is an emergence of intelligence, and we see the same in AI right now as the as the models obviously partially become better at doing certain things but I think most of the improvement comes from just the cost reduces so you can do much more with the same amount of money and therefore you have the the notion you have this experience of more intelligence. Let me put it like that. Then there's quite a lot of truth in that. 

And I'm just wondering because that then translates into "I can, the AI is writing a lot of code and it's doing that you know does the code become better as a result of that?" Now I don't mean more elegant or more effective because obviously it can't be because it must be the opposite. But if you add it up if there is more code and if we disregard the efficiency and the power requirements or anything like that but is there notion that the code actually is there a measure for that? Can we see how it becomes better because the AI is doing that? 

[00:28:35] Tyler Dunn: At the moment, it's I mean probably a billion dollar question, right? Maybe it's always been in software, right? Like how do you measure, right? Whether it be productivity or quality or or things like that. I think this is actually the reason that like you're going to see a big reason why you're going to see engineers still be a huge part of this in addition to like trust and risk and capabilities really the system today. It's that like especially as long as software is being built for humans. 

What that measure is and what it should be is like a choice of taste, right? So like the way that I always like talk about it is like there might be 10 ways to implement something, but often there isn't actually like an objective way of saying this thing is better than that thing. It often comes down to like how that engineering team, the culture that they've created, the people involved, what they define as great software versus, you know, I mean some other company might have a different definition. And so I do think that the ability to like we're going to be much better at expressing that taste because we kind of have to or because the agents pull it out of us. And then that taste is going to because it's more legible. It's going to be more consistent across the entirety of the codebase and it's going to be more collaborative than it's ever been instead of it being kind of trapped in my head and implicit. It's going to be a shared collective kind of thing. And that's going to be the main brunt of the work of the developers is like figuring out kind of what are the right vibes to use the the words of 2025 for this particular codebase and this piece of software. And then you know what I mean in some cases it will literally be just kind of vibe based where it's like oh I just believe this because of my past experience or my personal philosophy but in some cases they people also might put in measures and I think that's going to be critical right so it'll be like maybe downtime is something that matters to you right maybe throughput is something that matters to you like what matters to you right given a limited system and constraints and energy and cost and all of that like you need to figure out for your situation and often like the market or the business will help really shape that and as it always has but I think effectively it's going to come down to like that particular engineering culture or that particular software situation and what the right taste for those people is at that point in time.


[00:30:39] Jens Lapinski: Can you measure that?


[00:30:41] Tyler Dunn: I don't know. Yeah. I mean I think the thing is if you could measure it and maybe one day we will be able to then you probably don't need humans, yeah I mean then okay now if you have a measure like the history of AI systems is, once you get a measure then that you can build systems that model and optimize against that measure.

[00:30:57] Jens Lapinski: Totally different question. I mean I've I've always believed that sort of like the whole crypto thing It's really interesting in that humans don't really need programmable money. We have really no need for it really, right? Because we it's fine. We we we just but machines can use programmable money. So we've invested in that space and and but I always thought that the the way in which machines could program their money in a sense would probably end up being different from the way in which we think about it. Computers obviously use machine code. I mean at the at the end it's all machine code and I understand why Claude or whatever you know it programs in the way in which it does but If we gave them free reign, if the AI just said if we said to a system develop your own language, how to do this job, and do it on the basis of everything that you know and then would probably be I don't know what the end result of that would be. Are we at the point where that's already possible? Have you seen that? I'm not deep enough in this space to know that but my intuition tells me that this has to come about at some point in time over the next few years if it hasn't already. 

I think the machines will end up writing completely new programming languages and do this in a completely different way that has never been done before. And they will do that for code. They will do that to program money. They will do that to do whatever they want to communicate with each other. And these will be completely new emerging protocols if you like or programming languages, whatever you want to call that that we haven't seen and are actually not made for humans at all. And they might actually be completely illegible to humans. Our brains couldn't actually understand what these things do. And I'm just wondering whether you've already seen something like that or whether this is only what is in my science fiction books.


[00:32:35] Tyler Dunn: And when I was at Rasa in 2020 there, I think it was a model from Meta that came out or whatever. And they the models when you had them talk to each other, they would invent their own language to talk to each other, right? Like English is actually not that efficient of a communication mechanism or not even English, German, like natural languages that humans do, right? Like it'd be better if we could communicate in bits and bites. It would be much faster. But like the I mean my background is in cognitive science. So like the architecture of our brains are set up for for natural language, right? And so that's why it makes sense and that's why we're having our machines communicate in that and that's why like when we have them show their thinking and stuff, it's done in that way because not because it's optimal probably for them, but it's optimal for us. 

And I think it really hints at you I mean what I believe is is really the limiting factor which is trust. It's not intelligence in the world. So like I tend to view AI as a normal technology at least as of right now. You know, I mean I've watched these trajectories kind of go where like the limiting factor like same with electricity and the internet right was like people changing their behavior and adopting it and diffusing it and and things like that. And so are we heading towards a world where there'll be definitely new programming languages, and new software packages and things that are not human readable 100%. I definitely believe believe that. But it's going to take some time for humans to build trust in it, right? 

Like, am I if I had an AI agent that wrote everything in in Go today versus is I don't know some other variation Go 2 or whatever that I that is I don't understand right like in their equivalent I'm going to always today go with the one where it's like okay like even though I'm never going to read the code on the off chance that I would read the code right I could hire somebody to go figure this out right? Like there's certifications by some standards body that says go is a a language you're allowed to use in production and finance or whatever like there's all these like systems we built around things that like allow it to not only be legible today, but also allow it to be the basis of trust that we wouldn't have for those. And so, I definitely think there will be like smaller software projects, and I'm sure there already is today where people are are creating some really cool things, and like those as those go from toys and prototypes to production stuff eventually larger systems and bigger enterprises and stuff like that, will be like "hey like this startup that's eating our lunch is like using this language that or not not constraining themselves to using existing programming languages", and then that will have the market forces that cause them to do it. But I think we're we're still a little bit ways away from that.


[00:35:02] Jens Lapinski: If we're on that level of abstraction and then we could say that because you use the word trust quite a lot then then Continue is like the trust layer between what's good for them and what's good for us.


[00:35:10] Tyler Dunn: Exactly. So why did we call it Continue is because we viewed it in the future it was just going to be a "Continue" button. Right. So the way that the human expresses their trust is they just hit "Continue". Right. And so in some ways it has weird dynamics where that feels a lot like a slot machine or maybe a slot machine in the world of of AI that I don't necessarily like. Right? And there's things to be figured out like how joy it is to spend all day just pressing the "Continue" button. We're going to have to figure out how to like reframe that and think about that in a different way. But I think fundamentally you're right that that the continue direction in essence is all about like basically making it to to get helping us get to a future where you can make it super easy to build that trust and then express it to the system by hitting that continue button.


[00:35:48] Robin Harbort: So maybe in the future you have your brain to computer interface. So we will have think only code then the code will be translated to some uh Chinese science because their token efficiency is out of the roof and then we trust and "Continue".


[00:36:09] Tyler Dunn: That's even further down the road right like...


[00:36:12] Jens Lapinski: in space you know in space that.


[00:36:13] Tyler Dunn: Reading from the brain is going to be much easier than writing to it and see if that's even possible but that's a that's a discussion for probably a little bit too far out out of the out of the the bounds of this this podcast


[00:36:22] Robin Harbort: Ty, that was awesome! It was a for me it was a really interesting journey because I don't code but it's really interesting to learn about it.


[00:36:21] Tyler Dunn: I'm glad we we kept it at a level of abstraction that kept you engaged and excited about it because it's always a thing, right? How do you keep it technical enough but also not not technical too much, right? So that everyone can enjoy it.


[00:36:45] Robin Harbort: I will I will put it into claude and uh make it more easy to understand.


[00:36:47] Jens Lapinski: Nice. I'm looking forward to seeing you know you launch this new product and then you know, that's at the time that this gets released this will be synchronized.


[00:36:58] Tyler Dunn: So that's where it's perfect timing for y'all making this happen. Really thankful for y'all bringing me on and getting the chance to talk about it because it should work out timing wise that later this this month we've launched it a couple times already, but this is the big one where we're like, "Okay, we figured out product market fit. So now if we pour gasoline on this thing, it should get big again." Um, so that's the hope.


[00:37:17] Robin Harbort: Thank you very much. Thank you.

Thanks for being here. If you enjoyed this episode, support us by leaving a follow and share the Cutting Edge AI podcast. See you next time.