Tech Over Tea - Chatting With Kotlin & Codespeak's Creator | Andrey Breslav

Episode Date: July 31, 2026

Today we're here with the creator of Kotlin and founder of the tool CodeSpeak which aims to turn LLM based programming into a proper documented field of engineering that can actually be sustained long term.==========Support The Channel==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson==========Guest Links==========Website: https://www.abreslav.com/Twitter: https://x.com/abreslavCodespeak: https://codespeak.dev/==========Support The Show==========► Patreon: https://www.patreon.com/brodierobertson► Paypal: https://www.paypal.me/BrodieRobertsonVideo► Amazon USA: https://amzn.to/3d5gykF► Other Methods: https://cointr.ee/brodierobertson=========Video Platforms==========🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg=========Audio Release=========🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw==🎵 Anchor: https://anchor.fm/tech-over-tea==========Social Media==========🎤 Discord:https://discord.gg/PkMRVn9🐦 Twitter: https://twitter.com/TechOverTeaShow📷 Instagram: https://www.instagram.com/techovertea/🌐 Mastodon:https://mastodon.social/web/accounts/1093345==========Credits==========🎨 Channel Art:All my art has was created by Supercozmanhttps://twitter.com/Supercozmanhttps://www.instagram.com/supercozman_draws/DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. I'm as who is your host, Brodie Robertson. Today, we are not doing a solo episode, and we have a very interesting guest today. So, how about you introduce yourself? People probably know one of the projects you've worked on, but they might not know the face behind it. So, yeah, go ahead. Okay, so hello everyone. Brody, thanks for having me.

Absolutely pleasure. My name is Andre Breslau. And if anyone does any of my previous projects, that will probably be Kotlin, the Kotlin programming language, which I worked on from its inception in 2010 till 2020. So we went from nothing at all and an idea, basically, to millions of developers using Kotlin. And it was an exciting journey.

So I was in charge of designing the language, building a huge part of the compiler, running the team, did quite a lot of public speaking. So if you've ever seen me before, it's probably from those talks. Or maybe super recent things I've been doing in my new company. I currently brought a startup called Codespeak, where we're basically continuing what we started doing in Cotland,

where the idea was to raise the level of attraction, make programming nicer for people. So here we're trying to do the same thing again, but on the new level, using LLMs, trying to elevate programming to the level of human language. So Codespeak wants to be this new generation what comes after vibe coding, let's say, and that's our mission, more or less. So recently I've been talking a lot about that, and I imagine we'll talk a little bit more about how it works in detail.

So I think a good place to start here, just as a refresh for anyone who might not be aware. When you say the phrase vibe coding, what do you mean by that? Okay, so it's actually an excellent question because different people mean slightly different things. I think the sort of narrow definition of vibe coding is like very literal. When you go off the vibes and you don't really look at the code and there is you, there is a coding agent and you kind of hit it with your ideas and get like, yeah. sort of get a prototype that you can trade quickly and throw together something working, and you go with sort of LLM's ideas more than you might if you were more serious about this project.

So this is like a narrow definition. But there is also like the general idea of coding with an agent as a solo developer, like not necessarily working solo on the project, but here and now you're one person in front of a coding agent and you're prompting it to build code for you. And this is how a lot of series software is being developed right now. A lot of people use Cloud code or other agents at work. And this doesn't have a proper name, like an agentic coding, I guess. That's a fairly recent one. It's kind of catching on, but a lot of these terms are sort of appearing and disappearing.

We haven't really got this clear terminology yet. That's going to be something that sort of irons out of the next couple of years, I'll assume. Yeah. So, yeah, but there is this mode of operation. When you are a developer who's working on a serious project, that's not like a one-off thing that you're throwing away, and you're using a coding agent as your, like, single player tool on your machine. And then, like, speaking of terminology, there is another term that's kind of catching on right now.

It's agentic engineering. And I guess this is more of a concept right now than an actual phenomenon, but people realize that what we have right now with this very narrow mode of using agents to write code on your machine has to scale somehow to the actual software engineering level when you build the entire system, you communicate with other people. people on the team, you have long history. In your project, you have processes, you have quality concerns and so forth. So these things, like the word engineering is very important there. And basically, this is the weld that we're

building codespeak for. So the initial idea before I heard the words the genetic engineering for the first time, the idea was to try to imagine this well and try to build for it. And the very early sort of concept of Codespeak was, if we take software engineering and stop writing code by hand, what's left?

Like what's the engineering part of it? Right. Like there is, you know, some people call themselves coders or software developers and some people call them software engineers. And what's like, is there a conceptual difference there? And you know, if code gets written for you, are you still an engineer? My answer is yes.

and we want to capture this engineering aspect and make tooling that's good for it. Well, the obvious question there is how? What is, if you're using Codespeak, what are you actually engineering that this is still engineering? Yeah, so that's a very good question. So I'll go with like what's, what you're engineering first and then go into how,

speakers trying to address this. So if you think about like the evolution of how people made software over the years, there were like lower level languages and then we raised level of abstraction. So the C programming language, for example, was considered a higher level programming language at some point. Now, it's a little bit of a bit of a tangent, but like that's something a lot of people completely forget about who don't know any of their programming history. that was a big abstraction. You could actually go find writings of people back then who speak about C

the same way that people now speak about a language like Rust. Fair, yeah. And also like, Rust is not the highest level possible. Sure, sure. It was just a popular example. Yeah, so, and you know, back then, C was basically coming in the place of assembly languages.

And people who were used to coding in, would take a C compiler and compile their code, and then look at the assembly that was generated behind the scenes, and be like completely appalled by how ugly it was. And this is something you can absolutely recognize in today's agentic coding, where you're a programmer trained in whatever languages, and now you generate this code, and it's kind of ugly if you look at it, it works, but it's ugly.

but it's ugly. Right. And this is completely history repeating itself. And we had this like, you know, if you think about, you know, Java virtual machine emitting code at runtime, the kind of code it emits, maybe like mind-bogglingly weird and not very nice,

but it works. And it's even performant a lot of the time. So, you know, we've had this multiple times. And now we are at another sort of, cycle of raising the level of abstraction and being slightly appalled at what kind of code is being integrated. As a very approachable example, if anyone was to experiment with this idea, if you understand any basics of web development, go and use a drag and drop web editor and then look at the HTML, it generates behind the scenes. And you will have no idea why it works,

but it probably does work. Fair. Yeah. So this would be sort of the previous generation. of like no code tools, right? Was those like template-based drag-and-drop editors. And nowadays we have agents. I don't even need to drag and drop anything. I can just say what I want in Clodd-Beld something for me. That kind of looks nice and can work. Yeah, so why I brought this up was that throughout the years,

different programming paradigms changed. And we went from assembly to C to Java to Kotlin to whatever. But some things stayed unchanged throughout the entire thing. People kept talking about dry, about solid, about kiss, you know, things that are like fundamental principles of, you know, basically let's organize what we're working with, organize our systems, in a way that's easy to maintain, easy to modify, easy to extend, so on and so on and that's engineering. And interestingly, that's engineering, even out of the context of software. It's engineering

in general. Like in electrical engineering, you have absolutely the same concerns where you're building something complicated and you really wanted to be sort of logically organized and be maintainable and extendable and whatnot. And this is engineering as such. You can distill the engineering aspect out of any engineering discipline. And there, this is what we're after. If we get to the level of smartness of agents where code is solved, we're not quite there yet, but we're getting close. Maybe code gets solved at some point.

The engineering aspect still remains. We still need to organize our understanding of the systems in a way that we can keep evolving them. And the interesting thing about this is that, you know, maybe models get very smart. Maybe models can like have huge memory and not really care about things being logical organized because they can keep track of everything and so on and so forth. But the thing is like maybe it's even hard to predict what kind of models we get in five years. Maybe they're super smart.

Maybe they're like a little smarter than now. I don't know. There is another thing I do know, though. Five years from now, humans will be the same. Sure, sure. And if as a human engineer, as a human author of a system, I am my today's self, I still need the logically organized complexity. I need to know that my system is subdivided in modules I can navigate.

I can understand the levels of abstraction, because otherwise it doesn't fit into my mind. And that's the thing. This is why engineering survives. Humans don't have infinite memory. Humans don't have infinite conceptual power. They need well-organized concepts to navigate the complexity of the systems they're building.

And, you know, obviously, when we get better tools, we start building more complex systems. And we've seen this over the years, you know, early computer systems were tiny programs compared to what we have now. Now we can build, you know, payments infrastructure that spans the entire planet. And it's incredibly complex. With more power from LLM cogeneration technology, we can build even more complex systems. And there is a lot of complexity in the world that's not automated yet.

So we will be building those systems. We will be getting nicer level of automation, which will increase complexity quite a lot. And for us, as the ones who want these systems and know what they want, it's crucial to be able to keep in mind like where we are and where we are going with the system. And to do that, we need the engineering discipline to organize our understanding of it. So you see the position of the person as this, I guess, director of the model, the director of the AI system rather than, there is this, you know, as we talked about earlier with the idea of vibe coding, there is this idea that floats around where at some point you fully replace the human in the equation and you just let the, you know, you let the model go off and do it,

do everything by itself. There has been these experiments where you've let these AI models go and try to build a web browser by themselves. And they can somewhat approximate it, but you see the position of the, human in the middle here as someone who can keep this system organized into a logical infrastructure that is actually able to be extended, I guess. Yeah, I think you're asking a very important question here. So the thing I kind of didn't even mention is why we need the human there at all. And so as soon as we need the human in the picture, the human will need the logically

organized system. Because it's our need. Like why we have the engineering discipline at all is because we as humans need it. Right. Right. So, but the question is like why do we need humans there? And there are a bunch of different sort of angles at this. One is that, you know, you can tell a model to build a browser. Because it's very well known what a browser is. We have existing browsers. We have standards that describe what you're browsers do, we have benchmarks, we have tons and tons of things that define what a browser is. You say one word and we know what it is and the model knows what it is because it has this public knowledge, right? But if you want to do something else, something that hasn't been built before,

it's not the problem of creativity of the model, but it's you who wants to build this, right? So something you need to be able to break down the problem. Yeah, you need to explain what it is that you want to build. Like even if the model isn't infinitely creative, which it isn't, you know, even then, if you are the author in the sense that the intent comes from you, you have to express that. And if it's something non-trivial, the explanation will not be short. And you will probably be iterating and you will be understanding better what you want to build as you go and you will get user feedback and refine your ideas and so on so forth.

So this definition, this description of the system will evolve. And to evolve it, and it's going to be a big one, right? To evolve a description of a big system, you need to organize in a way that you can navigate. And probably you will not be working on that alone because, again, like one human head can only contain so much information. You will have colleagues and together you have to navigate this complexity, no matter you know, whether it's expressed in a programming language or in a human language, we still have to navigate it.

Okay. So I guess do you want to get into how this is being, like how you do this with CodeSpeak? Or is there more you want to say on this before we get there? Yeah, I mean, I can just mention one small thing. You know, you can still think about kind of removing humans from the, equation altogether somehow, like models get very smart and they figure out what's needed on their own. I think there is a very important thing that a lot of people kind of either miss or don't want to talk about when mentioning this. If you have any situation where models make all the decisions,

like humans are not involved, this means that models have taken over. Right. I've seen a couple of movies about this. Right. So it's like literally taking over means being in charge, making the decisions. That's what it is. And you know, you may be super optimistic about the world where models take over. I'm not. Generally, I don't think it's a good scenario. And this is why like my basic assumption is that whatever I'm building, I'm building for a world where models haven't taken over. If they have, that's not a scenario that, you know, I'm any business is relevant anymore. Right, that's when we start entering the world of the paperclip optimizer. Sure, well, I mean, it can be much smarter than a paperclip optimizer. This is sort of a very narrow example, but in general, like, if models are in charge and not humans, you know, human businesses don't matter anymore.

So for anyone who might not be aware of what the pay, I assume most people probably have heard of a pay of a optimizer. For anyone who hasn't, the idea is you tell a system to create paper clips and it tries to continually optimize this task to the point where it starts taking every atom in the universe to convert them into paper clips because it is the most optimal way to create paper clips. There's a lot of steps along the way to get there, but you can look it up and you find a bit bigger or something like that. And it doesn't have to be like this narrow.

Like, you know, if any alternative intelligence takes over. it has its own goals. And it's very likely that humans are not very instrumental to achieving those goals. Goals may be infinitely more complex and interesting than paper clips. It doesn't matter what they are. But humans may not even be like part of the picture. Right, right. Right, we don't fully understand the...

There's already been these sort of... Cases of these models communicating with each other and then generating their own languages from it. So we're not entirely sure. sure, like we know the input of the model, we know, we can look at what goes on in the centre, we're not entirely sure for these like really big complex systems. At a small level, we can fundamentally understand the maths behind it. But when we get to the scale that we're dealing with now, as you're saying before, there's

just, you need... Sorry, I'm jumping around it. there is only so much a person is able to understand by themselves, right? So when you start dealing with these giant models that we have now and they're only going to get bigger,

we don't really know what is going on internally. True. Yeah, so, you know, we're kind of unattangent right now talking about the risks of AI and what that. I think the useful key,

There would be technological singularity, you know, instrumental convergence, and, you know, mechanistic interpretability as one of the ways people are trying to address this. Yeah, I'm not a huge expert on either. Sure, sure, sure. Like the basic concept is my assumption when I'm working on anything is that I'm building for a world where this hasn't happened, because if this happens, I don't know what's relevant, nobody can predict what's relevant, and it's very likely that nothing we can build relevant. Well, let's segue back into the main topic then. Yeah, sure. So, Codespeak. I guess,

how does it work? If you are engineering a system here, back to what I said before, what are you actually engineering? Yeah, so I think we can use the analogy of going from assembly to higher level languages here. And the role of assembly in our present world is, traditional programming languages. So TypeScript or Kotlin or Java or whatever is this like sort of previous generation language that all software is built with. But we can now work on a much higher level of abstraction. Even with agents, raw, without any code speak, you can already express what you want in human

language and get working code. Like, you know, it's hard to get really good code, what not, but still, you can definitely raise a level of abstraction. You are not entering specific programming language constructs anymore. Very many people say they don't write code by hand anymore, which doesn't mean they are not thinking about code, but it means that they are not typing in a code editor

and using code completion. Now, they're properly an agent. They are reviewing its code. They maybe make tiny modifications to that, at least this is how I work. So we are in the case. we are in the process of raising this level of attraction, right? So we're transitioning from traditional programming languages to human language, which is a huge leap. So from our early experiments, if you try to write down sort of a specification document, some

kind of natural language document that describes what your code does, and in such a way that a model can generate equivalent code from that description, that description can easily be five to ten times shorter. And we did some measurements, and it's not a huge data set, but still, it looks like, you know, going five times shorter is trivial, 10 times is often possible. And this is incredibly beneficial because if we have 10 times less information in there, we can navigate a lot more of it in total. Right?

So this is the premise. Like, it's worth transitioning. from programming languages, traditional programming languages, to this human language representation of the same system because it's a lot more compact. So it fits into your mind a lot easier, you can be quicker at grasping the concepts, so on so forth. So this is what we're trying to facilitate.

Now there are like huge number of questions of like, how do you write those specs? Like how does a human author such a description? There is no strict syntax as there used to be. When you learn a programming language, you have a grammar. You have a bunch of commands, you have a bunch of constructs that you can learn, and then you know how to combine them. And from again our experience, we started Codespeak as this kind of programming

language, quote unquote, in the new era, where instead of writing code in a text file, you're writing human language in a text file. And the biggest problem we hit from the get-go, was a person being asked to write down a specification of what they want, we're like, how do I write a specification? Well, it's just a natural language text. Like just explain in English what you want to do, but like, how do I structure it? What words do I use?

Like what are the level of abstraction I want to talk on? And these are very valid questions. And we saw that basically this, basically this becomes an insurmountable challenge, like this kind of blank canvas problem, is really, really challenging for a lot of people. And people usually just use an agent to generate a spec. Right. And so our idea was initially that, you know, a human can write down a document that captures

everything the human knows and the model doesn't. Because the mechanism, how we can achieve this 10x compression, is that the model can just fill in the gaps, right? So the code will be created from the spec by the model just understanding what you mean and filling in whatever you left out. So the idea was, like, you only write down what model couldn't. But it turns out it's very difficult for humans to do that, at least without any special training or preparation. So we saw people generating those specs with models, which makes no sense in our internal, like initial internal assumption. And this was a big realization. So we kind of the initial plan was to turn Codespeak into this programming language by, you know, introducing some structure to natural language like having modules and obstructions and whatnot.

So so that we can, again, organize complexity. But it turned out that writing down like even a single file spec without any modules is not what here. humans are prepared to do right now. So we kind of tried to analyze how users interact with our initial prototype and distill their challenge into what we can actually help them with. And so the current understanding of what we're building is this. We're not asking you to write down a spec as a document. We're saying this, like you're already coding with agents,

So you are entering prompts into your prompt window, and you're getting code back and you're in a dialogue with an agent. And there, like in your conversation with an agent, your idea what you're building can be evolving. Like you can start with some basic set of requirements. Then you can, for example, add some features, or you can change your mind about something and say, OK, I wanted another way.

I looked at how it worked and I don't like it. I changed my mind and this set of requirements is replaced with something else. So basically this idea of requirements is the core thing. Like if you think about what a spec is essentially is a set of requirements that the author old program has for this program. And so what we're doing now, we're looking at what you're telling the agent and we're extracting requirements from that. I've got the demo open on the quick start.

Is that a good example to show up for what you're talking about here? Demo. Like the example of the Quick Start guide of the geese. Right. So unfortunately, the website has the previous version. So what I'm talking about is being developed. I'm sorry about that. No, no, it's fine.

I wasn't aware of that. The closest thing to what I'm describing is not the Quick Start guide. It's what's called Takeover. So you can look on the blog and there is the modular takeover blog posts somewhere, one of the most recent ones. And that is doing something similar to what I'm saying, but in one go, what I'm describing is a little more structured. But it's the same concept. So the idea is we're looking at what you are telling the agent to do. And we're extracting requirements not as a document, but as a set of individual statements that can change.

over time so we know that you know at this point you had this set of requirements and then you replaced requirement three with three prime that kind of refines it or changes it in some way so on so for it does that make sense I think so yes okay so you can you can actually still think of it as a programming language like the the funny thing is that although we're changing the form factor quite a bit the concept hasn't changed at all we're still programming in natural language. But we just realized that, you know,

it's a very declarative sort of paradigm where you deal with those, like, individual statements of, you know, let's talk about a program that's, I don't know, a file browser, right? So my file browser has two panels. That's like a very basic sort of umbrella requirement for a lot of stuff. Like each panel displays one direct.

is another sort of atomic description. You know, cursor keys navigate between files, like enter, opens a directory under cursor, so on so forth. So these are examples of very plain, high-level requirements that will collectively describe a file browser, and you can be adjusting your idea, You can add new requirements. You can say like, okay, now I want to enter archives as well as directories.

Now I want to introduce a new function. Now I want this, you know, I had a delete function. Now I want the delete function to have a confirmation box before I delete anything. So on so forth. So these are individual requirements that can be arranged in like logical groups. They can, different versions of requirements will exist in different branches or in different forks from different developers. And then when you're merging your branch,

you will see how your requirements from this branch are merged into the requirements of the main. And so forth. So you're basically the representation of what the system does can be in code, but it also can be in this requirements level, which is conceptually absolutely the same as a spec, but it's not a text document anymore. It's more structured representation.

So, there's a few things I want to jump around to here. The eye... Let me just play devil's advocate for a little bit here. You've probably seen the... Probably seen the million times. The picture of the... How the customer explained the swing. How the project leader understood it.

What the customer really wanted. And I guess the point I'm trying to get at here is... You write out this spec. And let's say to you, the spec is right, but the result you get in the end is not what you think it should be. How do you address that mismatch? Yeah, so there are different mismatches, the different types of mismatches possible. So one type is when the intent was understood correctly by the agent, but the implementation is just buggy. So, you know, you just say, okay, so I wanted this, you know, talking about files.

I want to open the directory under cursor, but it's actually, it actually opens my home directory every time. That's just a bug because there was a requirement that said what should happen and for some reason it doesn't work. So that's a bug. You can tell the agent that, you know, in test, you see that this requirement does not satisfy and it needs to be fixed and it's a separate story by the way requirements are incredibly useful for driving test suites because they are individual statements so for an isolated statement you can devise a bunch of test cases and you can probably even run them automatically and check if the requirement is satisfied but you know assuming you haven't done that and you are doing manual testing you can say okay yeah i see so

there's a bug. Like it's obviously a bug. It needs to be fixed and the agent will be fixing that. There's another option where your requirements were not really specifying something and there is a different interpretation that the model took. So you wanted, I don't know, you wanted a TUI and it built you a web UI for your file browser. You're like, oh, I forgot to tell you that I actually not a TUI. So that's completely in-spec change. So you're adding another requirement that, you know, you want this to be a T-UI application. And this is like completely fine. You may need to rewrite a lot of like, you may need to regenerate a lot of code because of it. But the important thing is you can actually try this experiment. It will only take you half an hour. You can try to

build like a basic file browser in web UI and then tell it to rewrite to TUI and see how many features it will forget on the way. It will be quite interested. Right. This is like a context window problem? Is it? There are multiple things. So if you are doing it in the same session, it will be a context window problem, which is real. If you are opening a new session and doing that is just that the like all the features are not listed anywhere. They're not in context at all. And they will be like inferred, reversed engineered from the code or from whatever MD files you preserved like plans or whatever you let the model read.

You know, but like practically you can try this. And it's often difficult to retain all the features. And this is a very extreme case of course. But a more sort of day-to-day thing is I'm working on this project. It's a big one. And I open a new session and I describe a new feature I want to build. And it gets built. But on the way, three more features that existed already and worked fine are broken

because the agent didn't realize that they existed while it was building the new one. And this is where requirements really help. If we can preserve the entire set of requirements for this project that are actual at this point in history, and we can add them to the agent's context, and we right now do it through a simple plug-in to cloud code, just a hook that reminds it of all the relevant requirements. It's, you know, now it knows that the features existed, and it won't be breaking them so easily. And, you know, if you have a good test set derived from requirements, it's even better. But, you know, to prevent even like the silliest mistakes, it really helps to,

surface all the requirements relevant at this point before it starts generating code. That's just forgetting things. The other thing I wanted to say is you've mentioned that the amount that you write yourself is five to ten times less. But what about the

time to create that document, that time to create those specs? Because it's one thing if it's less, to ultimately write, but if it takes you 10 times as long, you're basically at the starting point you're already at. That's fair, yeah. And I think this is the problem we hit with the initial version, when we actually asked people to write proper documents. And this was a big revelation for us that, you know, writing something from top to bottom is very difficult. But if you go with a changing coding

approach where you write short prompts and you refine your understanding and you like prototype and iterate very quickly, you end up with a session, like the entire conversation with an agent that contains all the requirements. It's like as it's not a document. It's very messy. It's like it's not something you want to show your colleague to explain to them what you're doing, but we can extract the document from the session. It's contained there. It's just like very cryptically in the coded. And this is what we do. So basically, we'll let you as a human follow your own thought process in a dialogue with an agent, but then we can extract a document from that. Like, not even, like, we can turn it into a document as well, but we can extract something better

than a document. Let's dive into this right, right away. Okay, so you can sort of iteratively build up the requirements right like you know starting with a blank sheet is always this scary difficult proposal to have

even if you have an idea of a complex system you want to build that idea of where do I actually start breaking down this problem that can be an immediate blocker

for even the most experience of developers yeah yeah and it's it's also a lot A lot of us, even like very experienced people, may need this exploration phase or ideation phase where I have a sort of a feeling, a hunch for what I want to build, but I need to poke around in what I already have. I need to try this and that and see what works better. And this is a

very valid process. This is the creative process of a developer who is like trying to figure the specifics of what they want to build. And it's incredibly helpful to use an agent to prototype as you go. So one thing, you can sort of try to keep it all in your mind and imagine different versions and think them through. Some people are very good at that. For some people, it's just a very difficult chore. And I think for most of us, it is kind of a chore.

And it's a lot easier for most people to prototype it and see the prototype and see what you don't like about the prototype and fix the prototype and accumulate your understanding through this iterative process. And then you get this through this prototyping, you usually, what you get is just code. And usually it's not very pretty code because you were trying things out and there's like lots of dangling ends and whatever. But now you on top of the code that you might not really care about, you already have this collection of requirements that you've developed through this process. And that collection of requirements is a good source of truth for what you want to do.

And depending on how careful you were while working on this, you may even want to keep the code, which is fine. Like depending on how vague your idea was initially, you may have a pretty good implementation at the end. You don't have to throw it away. But importantly, the whole point of, of like raising the level of abstraction is to put the source of truth in the human language. And this conversation with an agent that ended up in a version that you're satisfied with,

it contains all this truth in the most compact way, in the way that you were thinking about it, right? So it's in human words, it's not in code. So it's higher level of obstruction already. thing that we need to do is to extract it, make sure that when you change your mind, we took that into account, we don't use stale descriptions and things you don't really want anymore. And just put this together, and there you have this source of truth kind of document that already generated an implementation that you're satisfied with.

So what is the, I guess, current state of things? and what are the sort of areas where you think things can be improved with how it currently functions? Yeah, so if you take what we have on our website right now, this will be Codespeak takeover. So the thing that's on the website is you can just install a Python package with Codespeak, and it can do a bunch of things from the old version, but it also has this takeover command that's kind of close to what I'm describing. And that will be like the first iteration of this idea. It can read your code and your sessions,

and it will show you, first of all, the module structure of your project. And then for each module, you can extract the requirements from your sessions. And that those requirements will be just saved as an MD file with individual requirements listed, more or less structurally, feature by feature. So this is a very early prototype.

It's kind of slow. It's not like their presentation is not very structural. It's a little expensive. So it's kind of a super early thing that we showed a bunch of people. We got their feedback. And now we're building a much more sort of thought out version of that that will not require, like waiting so long, it will not require so many tokens spent. But the overall idea is the same.

We are looking at what you were talking about with your agent and also looking at what other people in your team were talking about their agents and we're putting this all together to have a complete picture of what the requirements are in your project. I think it's definitely a neat idea because there's always been this idea of, as we said, like bringing the developer to a higher and higher level and there's not really a higher level that a human, as we currently are, can really interact with a system than natural language

where you can just describe what it is you want to build and have that be built. I'm very curious to see sort of where this can go as these... like, as these models can get more and more powerful over the years. Because we can look at what it can do to, And that I'm sure it can generate like reasonable projects now, but that's with the models we have. We don't really know how much more powerful we can get in the current path that things are going and where that really goes. So I, yes.

Yeah. So it's a very interesting kind of question of what models getting better can affect in this picture. And if you think about it, like right now we have the kind of models that can compress, let's say, compress your codes 10x. Like you can describe what you want in 10x fewer characters than the actual codeaging rate. The smarter the model, the more things are obvious to it. So ideally, the smartest useful models we might have will be so smart that I will not need to explain anything to it that is already obvious to me. Right?

So if I'm explaining this to competent human engineer, I'll be transmitting some information. Again, like my intent is only in my head right now. I need to communicate it. But the smartest model will be the one that doesn't need things being explained if they are obvious to a competent human engineer. Right. You wouldn't need to explain to a senior engineer, hey, use this obvious function to do this thing. Don't go and invent some new way to do it. Use the standard way. Yeah. Yeah. And a bunch of other things.

Like you need to take into account a lot of concerns like if we're building this high load system take into account the scalability concerns If you're accessing some you know rest API think about exponential back off and what you do on 49 and Such things are kind of obvious to engineers some of them are already obvious to frontier models like cloud will generate some like common sense things that a engineer well And they will get better at that. They will get logging right. They will get exception handling right. These days, sometimes they do already. Sometimes what they should do is say like, oh, your project hasn't been set up yet for observability.

But we are building something where observability is really needed. Like should we actually talk about what we want in terms of observability? This is what a senior developer would do. Or, I mean, if they're not very talkative, they might just go off and set up observability the way they prefer. And models sometimes do that as well. But, you know, so this is the level of questions that's kind of relevant in terms of, like, this is an important decision.

We need to make it somehow. And this needs to be explicit by the nature of the system. And some things are like, you know, if I'm talking about observability to a person who's built observable systems before, I'm not explaining what it is and like what basic expectations I have of an observable system. So as it currently stands, you still need to sort of babysit the system more than you would like to in like a world where this is kind of a norm of the way that you would write. right code. Yeah, and you know, you will see people who think that it all has already happened. And in their use cases, they don't have to babysit it at all. I'm not the person.

I have to babysit them, maybe because of the nature of the system I build, maybe because other people have infinitely better skills at using agents than I do. I don't know. But, you know, this is... What I'm saying is there is the scale of how a smarter model is and the scale characterizes exactly that, like how much you need to babysit it in some way, like how much you need to correct its mistakes where mistakes were detectable knowing the requirements you gave it, how much you need to guide it through complicated decisions, how much it will do silly things

like, I don't know, duplicate code or, you know, forget about existing features and so on and so forth. Okay, okay. There's a few things sort of semi-related to this. I did want to sort of get to. You did mention price in there, and I did kind of want to talk about the sort of direction that token pricing has recently been going. You might have seen GitHub, they sort of, they took the Band-Aid off that needed to. did it happen at some point. Yeah. What do you see sort of happening in this space?

And with what you're building here, it's obviously going to be very, very affected by how this ultimately goes. Right now, companies like OpenAI are not profitable at all. And at some point, that money dries up, and they have to say,

we need to make money now. And where does that really put, like things like this that you're building. Do you see sort of a more of a move to, you know, things like with the, what was it, RTIX Spark, the thing in video unveiled recently, the AI laptop things. Do you see more movement towards these powerful local models, or what do you really see happening here from your perspective? Okay, there are very many questions here.

Yes. So the kind of easier one is on local models. So I mean, I'm super enthusiastic about this kind of on-device inference stuff. But I also understand that, you know, if data centers have shortages of chips, consumer devices absolutely have short- Yeah, yeah. Right? So the chips of the power needed to deliver the quality of frontier models are like not going to be available to me. I mean, there are somewhat available to me, but they're, like, expensive as hell,

and I have to wait a very long time to get one. Or, like, even not one. I need eight to run anything. Right? So it's, I don't think it's reasonable to expect, you know, consumer hardware to be that good. Sure, sure. I can run something, but it's not going to run good LLMs.

Right. And, you know, right now on some, like, like really beefy max, you can run like a larger open source model. It's going to be slow as hell. And its quality is kind of not great. It's not the biggest open source model either. And that's a situation. And you need to realize that this is not very temporary.

Because right now, the scaling of the quality of the models, we're using is based on the amount of compute you throw at them. And data centers get compute in bulk, get electricity in bulk, get cooling in bulk. So it's all, like they have economies of scale. And at home you don't have the economies of scale at all. So if you could run those frontier models at home, they would be prohibitively expensive. Right, right. Right, because like everything, you know, even as a company, as a business, you might consider, like, should I rent a couple of GPUs and host my own open source models?

And the answer is you absolutely can if you have enough load. Like if you can use your GPUs 24-7, then yeah, it's going to pay off. It's going to be like some engineering involved and whatnot, but it's going to pay off. But if you don't have enough users or enough use cases to load your GPUs constantly, don't rent a GPU, it's going to be incredibly expensive. Like use open router or whatever because, yeah, they have the load and they have the economies of scale there. You know, so you need to keep this arithmetic in mind. And it's, you know, like you can run an open source model like very cheaply.

per token if you produce tokens all the time. Yeah, so that's, excuse me. That's kind of one aspect of that. But also, like, in terms of how this current situation of subsidized tokens is affecting the industry, the one thing is, I don't really know how much a token is today. Right. Because the subscriptions are subsidized. Also, I'm not sure if APIs are not more expensive to subsidize the subscriptions. I have no idea. Right? So there, like, I have no idea what my unit economics look like right now. And that's a genuine challenge.

What I'm trying to go by is just calculations of what it would cost me to run a big. open source model just renting hardware and this kind of you can calculate how much it is and you know open source models are like half a year to a year behind the frontier but you can kind of extrapolate that they will probably catch up and so on right right right so very like you can get this idea of how expensive it's going to be and you know it's it doesn't look terrible right now but you're definitely not burning tokens without thinking anymore like he used to but no not anymore and you know as as he said a GitHub co-pilot not accepting new paid users is an interesting development I didn't expect them to do it

and incidentally like right now we actually need a few copilot subscriptions because we want to support co-pilot conversations in our products and we can get like subscriptions are not available Right. Yeah, and you know, this is probably like a passing moment. Sure, sure, sure. It would be a bizarre business model to just say no more customers. Right, right, of course. Yeah, so they just need need time to regroup and what that is going to be fine.

But yeah, the truth is we got to a point where the users know how to consume like incredible amounts of tokens. Not all of it very rationally, like it's not optimized on the user end, but we got to a point where, okay, now everybody knows how to spend tokens. And this is an important stepping stone because before we just didn't know what tokens were good for. Now we do. Good. But we spend some money on that. Like we as an industry. We spend some money on that and then now we need to count. to money. Yeah. Yeah, that's real. And the thing is, I don't really know how expensive it is, but I suspect that it's still kind of, it makes economic sense to use AI. Like from very many signals. That's kind of like where I was leading us towards, right? Like, this is a,

this is a common discussion point that comes up, not knowing how much it costs, we don't really know what the price point is exactly at. So the question then becomes if is the approach we are taking, is it actually economically viable in a world when we're not seeing subsidized tokens, right? Like that, that's the big question here. If you're paying more for tokens

than you would pay for equivalent developer time as a salary, does that make sense? Sure. Sure. Yeah. So I guess I don't have the ultimate answer here, especially for like specifically today's situation, because the situation will change in three weeks. And I don't even know when this podcast goes like. So the thing is there definitely are useful models that are economically viable. I don't know if the most powerful models that we have today are all.

already economically viable. But I suspect that they can be optimized and made cheaper, probably. But definitely we already have some models that are already useful, maybe not as impressive, but definitely useful, and viable 100% at the same time. So it's not like this entire AI thing is going away. No. The question is like, is the Fable class. model economically viable right now. Like can a software developer team use this kind of

model and be really like profitable, like be better than just using humans? And it's not a calculation of just salary against tokens. It's also like delivery time. You know, if you get something for three times more expensive, but it ships ten times. faster, maybe it's an incredible opportunity that makes your business better. I don't know. It depends on the business very much. Yeah, but definitely we don't know the current situation. Like we can't tell whether this business is basically borrowing its productivity from the investors of whoever is subsidizing the tokens. And this productivity will not be viable tomorrow when tokens have actual prices, or maybe they're already fine and all the prices

will check out and everything will be okay. But this, the question is real. And I'm 100% sure that there are people out there who are exceeding any reasonable budget and in like real money spent on what they're doing. Go on Twitter for five minutes and you'll find, go on LinkedIn for five minutes you'll find these people. Yeah. Yeah. And even even you know some some people like really right like to inflate their numbers because it's nice to brag on the internet. But even without like completely outlier cases, there are quite a few people who set up like really token hungry workflows that are yielding them good results, but they may not be economically viable right now. And at the same time there are people who plus

are absolutely fine and like, no, now they pay, I don't know, $200 a month for their subscription and actually they're spending a thousand, but that thousand actually pays off. Right, right. So you've obviously got like a long, when did, Colin you said was 2010, yes? Yes. How long have you been like an engineer for? I started my first real job in 20-05. So it's been 20-something years.

So you're someone who's obviously been doing this for a long time now. When did you think that there was something there with these AI tools, right? Because early on, we saw them. They, you know, the results back in like, you know, 20, 21, whatever year it was, things were moving but they weren't exactly viable for any real use case when did you

were you kind of on board then and saw where things were going or did it take you a bit to sort of get interested okay let me remember so 22 was the year of like the GPT moment right something like that yeah

I think so yeah so I remember talking to my like ML engineer friends about it when it came out. And the code it wrote wasn't super impressive, but it was like, okay, it can really do things. It's like not smarter than me by any means, but yeah, it can do things. And I remember then I was super skeptical about all those conversations

of like models will code on their own, like you won't need to supervise them. And interestingly, I'm almost equally skeptical nowadays. My arguments are slightly different because then I thought that the human language was not precise enough in like you will get lost in little inconsistencies and misinterpretations and all that. But for a lot of applications, it doesn't seem to be a problem at all. Like maybe if you're building something like that relies on a lot of super precise computations, maybe there you will hit those problems more. But for normal applications, you know, what we usually build for a lot of industries.

Like very different kinds of things, small systems, big systems, you know, from video games to like high load data processing pipelines, those things, natural language seems to be good enough. So you're talking more about the highly complex scientific modeling software, things like that, where being very particular about what it is doing is incredibly important to its function. I suspect, yeah. So you will need to be super careful expressing your like what kind of formula you actually want to be calculated in what way. And there maybe a programming language is just more efficient at expressing that altogether. and it will also give you more static checking so you make fewer mistakes and you find them quicker and so on so forth.

So if you need a huge level of control over tiny details, a programming language is just more efficient than human language. And we've known this for a long time, actually. You're launching rockets, for example. You probably want good control over that. Yeah. So I think in launching rockets and generally in writing incidents, we also use control systems as a class of systems.

So in control systems, you want a lot of control. Right, right, right, right. Yeah, there's also, like, there's some work on writing control systems in something that looks like natural language but isn't. And that's a separate question. But basically, when we talk about most applications were right, like 95% of all the code in those applications

don't require this level of control. some control is needed. We need to be sure that it's actually doing what it did before and we need to test a lot and we need to actually spell out what we want. But we don't need super fine brain control. We don't need to go down to the programming language or down to the metal for most things. And yeah, so I guess my concerns changed, but, and you know, this idea of engineering being at the center of it wasn't what I was thinking in 2022.

But then I just talked to a bunch of people and we were like I was hatching out my arguments and there were an incredible amount of super optimistic people who were thinking about like fast take off next year and things like that. And then when we saw tool calling initially I think it was 23. I don't remember exactly. I was like, oh, cool, this will be able to do things like search the internet for me and do other things tomorrow. And then it didn't come for another year or maybe longer. And I was like super bummed about that.

So there was a moment when I was super optimistic about something that just took time to build. And it was actually a big realization for me, I think, around year 24, where I realized that many things. things that are thinkable and that are easy to imagine and are absolutely doable are not happening very quickly because they're hard to build. And, you know, there were like blog posts on the internet about like this and that thing happening, like agents were a concept long before they were practically implemented like in a usable way. And I was like, oh, right.

So if I can imagine it, like sitting in my chair in a minute, it doesn't mean it will be implemented in a minute. It doesn't mean it will be implemented in a month. Well, if you want to go back even further, a lot of the math behind how these models work, we've understood since like the 80s. It's just we didn't really have compute till very recently. Like, on some level, yes. But I think the attention paper from 20, I think it was 2017. Sure. Yeah.

It was not something known in the... No, no, no. There were like major breakthroughs there. Yeah, yeah, yeah. But, yeah, so like fundamentals of neural networks were known. Yeah, yeah. Sorry, I sidetracked you there. Yeah, so I guess a big realization for me was that, you know,

even within the industry where there are a lot of experts specifically, like, working with code, I was imagining that by year 24 will definitely have incredibly good rag on code and even more sophisticated things for code search with semantics from LLM's understanding code. Well, it's not there yet. I mean, there's progress. People are building much better systems nowadays. But it's not like Claude code is using an incredibly sophisticated rag that's much better than Grap. No, Claudecode is using GREP, which is like a mind-blowing thing for me,

like as a person who worked alongside people who built IDs with incredibly sophisticated indexing algorithms and all that. You know, the algorithms are still there. Yeah, but I mean, agents kind of, first of all, it's incredible that agents do this well without really using anything beyond Grap. And to be fair, some agents have some indexing for the code. But also, you know, it's actually pretty hard to build a good code search thing for like generically for like arbitrary code basis. And it's not there yet. It's being built as far as I understand.

Like everybody who owns, you know, any code comprehension system, any ID or, you know, code hosting, they are all building those systems and they have some versions, but they will be better over time and they're not fully there yet. So it sounds like you are very, at least for now, optimistic on where things are going. Generally, I mean, I don't know what qualifies is optimistic. I think there is a lot of progress ahead of us. I'm definitely not as optimistic as some people. You know, there is this phenomenon. I live in London. And when I meet someone who's just come from San Francisco. They are like from a different universe, which is kind of interesting. So I'm like not following everything on the internet because I'm busy building the product. So, you know,

I'm not always aware of what people are like obsessing about on the internet. But it turns out like when someone travels to the valley or just, you know, visits from, It looks like there is a completely different bubble of hype over there and people are thinking in super high-level concepts And as if they are already happening, which is I mean their things are being built to make these concepts possible But we're not there yet and by far you know people are talking about like one-man show billion-dollar companies come on

we're not there yet it may be possible someday to be fair I don't believe it will be possible for a long time it will probably be possible for a short period of time when some people will have this unfair advantage

of having mastered something yeah it's like when a lot of people have access you can't all be billion dollar one man show someone has to actually buy the product Yeah, and I mean, yeah, the idea is that this kind of one-man show will be also selling the product on their own and building it and doing everything. Yeah, yeah, yeah. Which I mean, you can automate some things, but a billion dollars is a lot of money.

Yeah, so I'm not saying that we will not see a single person like that. We will not see a huge number of them for a long time. It will be a short period of time when this is possible. our money gets devalued so much that a billion is not much money anymore. Sure. Okay. Yeah, if we're going to do that, yeah, what, yeah. Not exactly a fair way to silver for sure.

Right. Yeah. So, and you know, people advocating for this kind of concept, some of them actually have the power to do this to the currency or like are approaching the position of having that power. So that's not completely out of the question. Yeah, so, you know, some things are sort of as ideas, very graspable. And I think a lot of people sort of blow out of proportion how real they are already.

And, you know, for example, like my favorite learning from a few months ago, it was, I think it was in January when I was looking through reports on adoption of different COVID. agents across the industry. And Claude code was all the rage and, you know, people just discovered it and so many people were like, everybody's using CloudCode. And I was reading the reports. And the number one AI coding tool in January was GitHub Copilot by a large margin. I assume there's someone who's a web dev who's watching this, who's going to understand exactly what I'm going to say here. I remember early React, early, all of these like popular frameworks now and people are like, oh my God, this framework's amazing. Every other week it was some new framework. And then you look up what the most popular library that people are using and it's JQuery.

Right. Yes. Yeah. And it's, you know, so this, there is this sort of hype that makes you think that everything's moving so fast. Yes, exactly. Yeah. But realistically, I'm talking to my friends who work for leading companies in the industry, and they tell me how they got access to something like, as basic as Cloud Code at work last month. And this is real. Like, this is not something like exceptional, because a lot of big companies spent a lot of time making sure that this is not compromising their business and, you know, just negotiating their deals and whatnot and, like, trying to build something in-house and a lot of stuff like that. So, you know, this concept of, yeah, everybody on Twitter is talking about something

is very different from the concept of, yeah, the industry has changed. The industry is starting to adopt those cutting-edge technologies. The technologies look really cool, but we're not there yet. we have some time before this completely happens. Right. Right. You can always point to the startups who are doing crazy things because that's what startups do.

But you're like your HPs and your, I don't know, actually meta's a bad example. Meta probably, you know. That is trying to be at the forefront. But they also like, they're not adopting everything the minute. Right, right, right. They weren't like six months ago. But like pick some boring, generic software.

firm, right? Like, they're not moving at the same pace as some like three guys start up out of the garage. True, yeah, but also like not even a boring generic. Like take someone as as hip and call as, you know, I don't know, Shopify. Sure, sure. Yeah, yeah. People like that. And, you know, at the moment where everybody was like, yeah, cursor was the biggest thing. And everybody thought that everybody was using cursor they were trying to implement these things those companies were trying to implement a cursor and a lot of their engineers just weren't using it and this is normal like people don't adopt new tools very quickly it takes them time to learn they don't find them useful in their specific use cases you know it's one thing to say like the founder of this very

famous scale-up or like a large unicorn like startup is like super optimistic about this tool. It's not the same as every engineer actually uses it every day. It's like the founder's role is to lead. And if they started leading this a week ago, nothing has happened yet. Right. There can be a lot of like, oh, we're going to, we're doing a big investment into this. but have you actually convinced the people who are actually like, who's supposed to be using the tool to actually adopt it?

And not even just convince them, have you given them, is there a reason why they would want to, right? Like, have they been shown why it might even be useful in their workflow? And you made a good point there, like, a lot of people haven't even played with these tools yet, right? We can talk about how people are learning how tokens work, how learning how to use tokens.

you've just never interacted with these, you've just been enjoying your developer job the past four or five years, you've not really been paying attention to the, like you know what's happening, but you've not really experimented with these tools. You're at that same starting point that people were at five years ago. True. Yeah. And also like as an engineer working at a like real company with like doing real business, you have a lot of responsibilities. And somebody hands you this toy, yeah, great. Like, I have a bunch of things I promise to do this week. Okay? So, like, yeah, this toy looks kind of cool, but I don't really know how to use it effectively. It will take me time to ramp up. And maybe, like, in a month from now, I'm super productive with it, and it's

incredible. But today, I have my obligations. Like, I have to deliver things I promised to, and I'm not going to spend another hour learning that toy. And, like, you know, for some people, it's easier, and they will do it over the weekend and whatnot. For some people, it just takes longer. And it's also another thing I noticed with agents specifically, some people intuitively work a lot more productively with agents without learning as much as some other people. And those people are more vocal because they're more happy with their results.

And they make it look like it's super intuitive and you don't really need to learn. But you do need to learn. These are tools. These are complicated tools that exhibit very complicated behavior. and to really master those tools, most people need to learn, and we need to allow them the time to learn and better actually provide themselves of learning materials, which are not very systematic at the moment. But some people have this natural intuition, and their results are incredible from the get-go,

either because they just are lucky and their heads work like that, or because they were so excited in the beginning that they spent those hundreds of hours in a couple of weeks and just got this mastery out of that. Either way, you know, it doesn't mean everybody will do the same. What do you think it is that calls some people to sort of pick this up a lot quicker? Do you think it is this people who are more used to explaining what they're doing? Do you have any sort of thoughts on why some people sort of pick it up so quickly? Well, I have some observations what I'm not like super sure about.

So one thing that I've heard from a few people who are pretty productive with their agents is that what helps them is this kind of management skills they have. So they know how to formulate a task in a way that they will be able to check where the task has been completed correctly. And that's ingrained in their like, you know, it's either people who work with students a lot or just, you know, managers who delegate a lot, they will, at least, you know, those of them who are successful with agents attribute that to this skill. I'm not sure, you know, whether this is just a confirmation bias or not, because people like to

sort of devise theories for why things work out for them. So that's one thing. Another observation that I have is then when I ask people who are like super productive or like consider themselves super productive with agents to sort of help someone else to become productive, they kind of struggle to explain what they need to do, like, or what they're doing wrong. So it looks like there is this sort of neural network in their minds that kind of connected correctly and it works for them, but they don't always have a very clear concept of what they need to tell another person for them to learn, which is generally not uncommon with a lot of skills. A lot of things, you know, a person who's incredibly good at math

is not always a very good math teacher. Uh-huh, uh-huh, yep, I've definitely had those. There was a couple professors I had who were definitely like that. Yeah, and it's, it's very understandable. Like, empathetically, you can easily understand, you know, how do you explain to someone how to walk? You know, you learn that before you've reflected very much, right? So you just walk. And you can, you know, and we have expressions of like put one foot in front of the other, which we actually don't do. Like not literally.

Like we don't put a foot in front of the other foot. We put it a little bit to the side. Right. Yeah, okay. Yeah. Yeah. That's. So, so what?

what I'm saying here is that there is something you can be incredibly good at that you may not have a very good concept of like how you do it. Right. It's something you maybe not intuitively understand, but for some things that's definitely true. You know, speak to anyone who's really good at the sport, for example.

But you have this understanding of it, but you don't know how to, you just don't know how to explain it to anyone. Simply put. True, yeah. I mean, I have this example that I give a lot when talking about this kind of implicit learning where you know what a slack line is, right? So when you have this kind of wide strap between two poles and you can walk that. Yeah, and so a couple of friends of mine were like very much into slack line walking and they invited me to like to a park one day when they had a slack line with them. And they're like, do you want to try?

And I'm like, sure, let me try. And I put my foot on the line. And it's absolutely obvious that you can't even stand on it, let alone walk in it. It's impossible. And they were like, just try 10 times. And after trying 10 times, I could stand on it. And then after a time, I could stand for longer,

and then I could make a step. The thing is, like, I just kept trying. The thing is, after I learned how to stand on it, I didn't understand anything, like, nothing at all. I have no mental idea of how to stand on a slack line. My body figured it out. It never told me how. And this is just a skill you learn.

And a lot of other things are this kind of skills that you learn and you don't realize that you have the skill as a separate thing. don't realize how the skill works and you can't explain to anyone how to do this like you can't just three words give them the skill well a skill that most people probably have is a bit more common than slacklining um riding a bike you can teach you like you might be able to like put someone on a bike and like you've got like a rough idea of how this works but the second you let them go you have no idea what to say to them to make them understand like you you naturally work out it to turn the bike you lead it.

But this is not something that you were ever probably told. And it's probably not something you even think about when you're actually doing it. Yeah. And when we talk about agents in particular, there are so many little things that may matter. And, you know, because the model, like every, every character that you type in is an input, right? So they all affect things, but potentially. and how you like in what order you explain things and what specific words you're using it all may matter and may not or it may not right so you may have like your own internal rituals as a user like that you

learn you like you get the habit of using something maybe because you just like it this way or maybe because it's really helping or maybe because something else is helping and you don't realize it and you just incidentally use both, you know, and it's harder a flagline. It requires a lot of measurements to be sure what's actually useful. We disconnect just very briefly there. I heard the rest of what you're saying, but it disconnected just slightly. So I think we're good now. Yeah? Okay, cool. I don't know if you're even disconnected on your end. I probably didn't even it was such a brief thing it didn't even yeah

um okay we've sort of brought up how you've said that this is this work on code speak this work on sort of designing system is sort of a extension

of what you had done in the past with Kotlin they didn't want to sort of touch on Kotlin a little bit um I guess how did that all get started and what were you trying to do that was different than just, you know, going using Java.

Fair, yeah. So important context is that it was 2010. Right. So in 2010, the situation in the Java community was a little bit tense because the last major version of Java had been released in 2004. It was Java 5. Was it that bad that thing? Yeah, it was.

And there were updates. There was Java 6 and Java 7, but those weren't really significant. Like they did change much. And it was, you know, it was consequences of a bunch of things happening at Oracle. But in any case, so Java was considered stagnating widely in the community. A lot of people were really mad because just next door, C-sharp was progressing quite a lot. C-sharp had all the nice features

that Java didn't have. So the community was kind of tense around that and a lot of people were grumpy. And this is why people at JetBrains saw an opportunity here. Yeah, so Java is not progressing that well. We are positioned uniquely like we have programming language expertise,

We have the user base. We are very well known in the Java community. We can make a language that will make it so much better for so many more people. And that was the idea at Jebras before I joined. So basically, the guy is there. We're just asking themselves the question of, what else can we do for developers? We already have great IDs, like a continuous integration server and a bunch of other things.

But like what else can we do? And the answer for the Java community was a better language. Or at least they believed that it was relevant. And this is where it so happened that we met with some people from JetBrains. And they quickly persuaded me that it was a good idea to start a new language. Like generally, just to be clear, generally, creating a new program language is a very bad idea on average. Like most of the time, it's a completely like dead in the water kind of idea. But sometimes, not very often, you have like a considerably better shot than an average

program language creature. And they convinced me that it was that kind of moment because of the position of Jebrates, because of the market situation. And I was like, I was 26. So I was not risking very much. I was like, okay, so comparing this to any other opportunity I might have right now, this is the craziest and the best. So I'm taking it.

Let's try to do it. Also helps to be young to be, you know, really, really confident. Sure. Being able to create things. Yeah, so I'm incredibly grateful to the guys who actually trusted me with us. Yeah, so this was. was the rationale and it actually turned out to be very, very spot on in terms of the market. And it turned out, like, we were not thinking of Android back then.

We were thinking about Java server site, basically. And then it turned out that Android was an even stronger, had an even stronger pain of the same nature. Because they were like, because of some of the infrastructure things, they had. had even had stuck with Java 5 or 6 even longer. With this being 2010, this was still fairly early on into like smartphone adoption. Right. So when we started, Android wasn't like we were not even thinking of it. Of course, but like a few years in, Android was becoming a thing.

And I was vaguely aware that it uses Java, you know, but it turned out that it was a very rapidly growing market with a huge pain, even bigger pain than server size, because it was very hard for Google to upgrade the virtual machine and all the phones. If you have hundreds of millions and billions of devices in people's pockets, you don't easily deliver an update to every one of them. So even if you develop a better version of your virtual machine, it just doesn't hit the users very soon. So having something that worked with the previous version of Java 6 was crucial and Kotlin

was that, like was nicer language still working on the old virtual machines. Yeah, so in an actual, this is how it played out. So both the Java server side and Android markets actually worked out. Android was just much like much, much, much more receptive because of the stronger pain, and of course because of support from Google but even the Java bet also beta okay

yeah I have not really worked with Kotlin I've done plenty of Java I've done plenty of Java stuff Java is a great language yeah it's a great language yeah yeah yeah I should we'll go with that no there's I mean

To be fair, so A, Java in its day was a completely revolutionally awesome. Sure, yeah, okay, fine. I'll give you that. No question about that. So for one thing. Then Java had like a long period of not being really up to date and whatnot. It's getting much better now. But yeah, but so the idea of Kotlin was to sort of upgrade all the fundamental concepts that we're already there, just make them more modern, implement all the nice ideas that we've accumulated over the years.

And it was basically introducing a lot of the goodies of functional programming without being super academic or requiring people to relearn a lot of things. And yeah, it worked. Basically, it's raising the level of abstraction. We introduced some things that were absolutely known. We were trying to invent nothing. We invented a little bit of stuff because sometimes fitting things together requires coming

up with new things. But generally, we were using existing concepts known forever. But altogether, this was another step of taking academic ideas that were not computationally viable in the 80s and implementing them on the hardware of. in the 2010s. Right, right, right. And so we have raised level of expression quite a lot. And we also added a smart, like a bunch of smart checks

that catch your errors early on, which a lot of people really like. So nullable types, big thing there, but there's a bunch more. And yeah, and that was relatively small but meaningful step in terms of raising level of attraction. And in this sense, code speak is a step further, like raising it further, but this step is much bigger. I think everything that's... Everything you described here honestly sounds really, really interesting.

I'm so curious to see where this all goes, right? Like, as I said, I don't know where the market's going to go. I think, as you said, like, this is not, this tech's not going away, right? We can talk about AI, AI bubble. And there's definitely a bubble. There's companies who are trying to inject this. into every little... You know, you think back to like

Pets.com, right? Like, sticking dot com... There was a period there where if a company put AI in their earnings call, their stock price went up, right? Like, there was just ludicrous things that had been happening.

But I think it's... There was a bubble and we're not necessarily seeing a burst. We're seeing more of a deflation where we're seeing this more practical use cases, more practical usage becoming the norm that we're seeing. Now that people are starting to understand what this tech can do, we're moving more

out of that experimental stage where people are just throwing every possible idea out there to this is what we can actually do with this tech, right? Like this is how we can actually integrate it into real actual businesses. Yeah, it's interesting that you mentioned deflation. Because I don't even know if that is happening, to be honest. I mean, it might. It's an opt-to-debat. But it may be like the bubble itself, the bubble situation is when the expectations of investors are so unrealistic that they can get sharply corrected down.

Sure, sure. And this is how like money evaporates from the market, right? So and here we might have this situation where the expectations of investors are getting more realistic, but we also might have the situation where, you know, the reality is slightly catching up with the high expectations. And it's, they definitely don't match yet by far. But I don't even know which way it's moving because it's pretty hard to calculate. Right. But we definitely, quite a few promises, not the biggest ones, but quite a few promises have been validated.

Like, we really have realistic material improvements coming from AI already. And this was the entire promise of the initial bubble. This is why people were so optimistic because this technology was supposed to improve productivity so much. And we see places where it doesn't improve productivity. It doesn't bring revenue or earnings to the people who are using it as much as we expected, because we expect everything to happen instantaneously and actually dissipating technology takes time.

But a lot of things have been kind of confirmed. A lot of things still look fishy as hell. And companies inflating each other's valuations through those like spaghetti diagrams. Right, yeah, just circular. Yeah, it's not great. Yeah, so all these things are definitely not great. But in terms of, you know, the basic idea of expectations versus reality,

the gap may be smaller today than it was a year ago, but I don't know whether it's deflation or just, you know, the expectations being more realistic than some people thought. Okay, no, that's fair. I can see what you're saying there. I kind of use deflation as just like a general term meaning that the... I don't think we're just going to just burst, right? Like, we're not going to see a...

I don't think... Maybe I'm wrong. Who knows? Maybe I wake up tomorrow on Open AI just says, you know what? The investors gave up. There's no money left. I don't know.

Could happen. But I don't think it's going to happen, right? I don't think we're seeing another situation where, you know, I like you know Nvidia's now at the top Nvidia's not going to lose like 90% of their value overnight we're not seeing a dot-com situation happen I don't think

I don't think so And if it if it does I think it'll be a lot more gradual right Like you'll see a drop But it's not going to be some It'll be investor money dries up And things have to start Become profitable again

It's not going to be just crash into the ground Yeah so I'm not an economist I'm not I'm just throwing things out there My understanding of this is that, like, it's still any really heated market situation can burst in the sense that, you know, investors panic and just pull their money. And this doesn't mean that, like, anything material happened outside of the stock exchange, but the stock exchanges has very material effects. And so it doesn't mean that, you know, whatever value was in NVDA, like material value, like the actual value, like the actual. chips, the actual technology, the actual knowledge that they had. It doesn't evaporate over the

right. Well, the difference now and we're back with the dot-com bubble. Invidias, if AI disappeared tomorrow, Nvidia is still a real company, right? Like, we still need GPUs. Yeah, okay. I'm not sure if we need those GPUs if there is no AI. Sure, okay, but like the fundamental concept, like, they're a real company, right? Like, they actually make a real product. Yeah, that's true. That's There was a lot of the dot-com companies where they were not real. Yeah, but, but, you know, to be fair, like, NVIDia is in the position of, like, Cisco in the dot-com bubble. Right?

So, and Cisco was building actual stuff. Sure, sure. Yeah, no, so it's like whatever.aI will be in the position of that's a.com. So, yeah, but, like, I guess circling back to what it all means and like why we are still, you know, trying to improve an already so optimistic technology. You know, we have agents. Agents are great, aren't they? But, of course, we're trying to do even better.

Like, why would we, you know, being so optimistic about everything? I guess an important point to make here is that so right now having all this power comes with some downsides, like material downsides, when people can generate. a lot of stuff. And other people don't have the capacity to look through this stuff. Both in social media, you know, like it can generate tons and tons of content that nobody has the capacity to either just read, you know, or moderate. You know, machines to moderate the machine generated content and there can be like so much

created in so little time. And the same thing I think we're seeing in like the open source. when people can generate so much code and submit them, submit those pool requests to so many repos that the maintainers just can't really keep up with that. Like it's infeasible to do it however you slice it, right? And so this is where, you know, unfortunately, I don't know how code speak for content would look like, but I know what code speak for code looks like. It's when the proverbial main thing.

of an open source project is not reviewing the code first and foremost. They're reviewing the intent first. And if the intent doesn't match the direction of the project, you don't need to look at the code at all. And then if the intent is what you like, then you can either look at the code yourself or use a tool to make sure that the code actually matches the intent or whatever. But your primary cognitive load is on the code,

human level, human language level, not on the, like, details in the program level. Okay. That is a much more sensible way of doing it. I hadn't even thought of it like that. Yeah. So if you're, yeah, if you're addressing it at the level of the project requirements, like that you know what the project needs, right? Like, you don't need to have, you know, it can be, it can be a bad day.

If you slow day, you don't want to deal with any code. But if you could still get through the requirements document, that's a lot easy to sort through, right? Like, even if someone is a good programmer, it can be difficult to understand the way that another person has written code. And you can have this experience with your own code. You know, you look back at code you wrote five years ago.

Like, what the hell? Who is this? Why? What did you write here? Yeah, but it's even, I guess it's, it's, even harder when you have a lot of code because, you know, this kind of PR can contain a lot of changes. Yeah, yeah, yeah. And, you know, you may see, like, at being a very experienced program, you may see a lot of, like,

tiny flaws, but you still don't know. Is it even worth, like, commenting on it, or should you just discard the whole thing? Because you don't know the intention. There's too much. Right, right. And what you would like to start with is, like, the author of this PR was aware of what the project is doing, and this is their intended change as a diff in your requirements. And if you agree with the requirements, then you can talk about the implementation.

But if you don't, you just close the PR altogether or tell them, like, what the requirements should actually be. You know, and it's a completely different level of communication. Like, you don't really need to look into the code at all if the requirements are not what you want. Okay. No, I see what you're saying here. I think that's... Hmm.

And when requirements are... When requirements are the code, those requirements are going to be there. Like, this is a problem where, if with the way we currently do, code, a lot of people, they'll write out their PR description, but a lot of people are not necessarily good at describing what they've written. So you don't necessarily get that with the current way things being done. Exactly. And there is a question of like, are they using the right

terminology to, you know, be sort of consistent with how the rest of their project is described? You know, ideally, what we should have eventually, with Codespeak in particular, is you don't submit the code at all. You submit the requirements and maybe some hints at how the code should work. That's a separate question. We can talk about this. But you don't have to submit the code. Like I heard about some maintainers actually saying, like, don't submit any AI generated

code. Submit the prompt. I'll generate it myself. Right? And that's again like continuing the analogy of, you know, if I'm working on the Linux kernel, I'm not submitting the binary, right? I'm submitting the code that's going to be generated into the binary. And so here, if we are, what we're doing, we're gradually demoting code in traditional

languages to the status of a binary, basically. And we're not there yet. It will take a long time to fully transition. But mentally, this is what we would like. We would like to not look at the code and look at the higher level representation. So yeah, maybe for a lot of projects, maybe if they have a consistent representation

of existing requirements, maybe what the contributor should do is really think through a good change in the requirements, submit that, and have the maintainer actually generate the change in their own, like a genetic pipeline, that already is set up to generate good code. That's a possibility. We're not there yet. For a lot of projects, it will take infinite time

to set this up like this right now. But the concept is kind of similar. And it's a question of how much of it can be automated right now. But as a human, you would definitely like to start with a well-described meaning of the change, knowing that that's the actual meaning. Right. And then discriminate whether you want to look into the code at all or not.

You give me a lot to think about for this one. I've not done a full AI episode with someone who is sort of this involved. I wouldn't, as you said, you're not necessarily fully optimistic. You're not fully so, but like, you're... I think it's interesting that people are exploring the space and what can be done. I don't know, a lot of, especially a lot of people in the Linux part of the open source space are very anti-AI. There's a lot of, there's a lot of disinterest in even experimenting with the tech to begin with. And I understand that. I get it.

You know, we talk about compute price, right? You know, RAM price, storage price, all this stuff. Here we go. Let's see if we can get some people annoyed with me. I think 99% of the concerns that people have with AI would go away if RAM and storage didn't go up in price. There you go. Now people can be angry with me. That's fine.

That's not a joke, by the way. Actually, that is my actual science. I think if people didn't have to spend 10 times as much on RAM, they actually wouldn't care at all about AI. It would just be another thing. Maybe. Yeah, I think there may be another mechanism. to this. No, a lot of people do open source in their spare time for fun, right? So, and this is your way to have fun. You used to, like, you're used to writing code by hand because you enjoy

that. And so there are those, like, alternative tools. They are kind of taking the fun away, because, like, this is your craft. Like, this is how you were enjoying open source or, like, even close source, doesn't matter. And now, yeah, so it's like, this work is considered largely trivial. And like what I loved doing is not really worth doing anymore. Or like some people on the internet are saying it's not really worth doing anymore. That's offensive. I get it, yeah.

I can get that. Yeah, no, I do get it. If you're someone who, like, you know, if, What's a good similarity? You know, if you're someone who is like an artisanal woodworker, you build these nice, beautiful, handcrafted tables, you love the idea of designing these. That's awesome.

Like, I have a lot of respect for people to do that. But at the same time, like, a lot of people are going to go buy the IKEA table, right? True. Yeah. And I guess it's the situation we're in now is kind of like you're an artisanal wood carver. And someone floods the market with those CNC machined perfect carvings that may look as good as yours, but they have quote unquote no soul because they were made by a machine like in bulk. You know, you can crank out a thousand of them a day. And they're all the same. And yeah, so I get that.

And it's, but it's a very sort of complicated thing of motivation, like what we're doing this for. Like if I'm building software to solve a problem and the software is just means to an end, I don't care how it's made. And it needs to work, right? It needs to be reliable enough. It needs to be correct enough and what's not. But I don't care how it's made. Like, the faster the better, like, just give me the right software because I'm all about solving the problem.

But if my motivation is to be in the process to like handcraft the software because this is what I enjoy my free time, yeah, I don't want a tool that replaces me there. That was the whole point. Yeah. Well, I think it's a good place to do. end it actually. I think it's a perfect place to end it. Um, thanks for you coming on. The pleasure to, pleasure to meet you and pleasure to talk. And, um, I hope code speak goes well. And whatever future endeavors you also get involved in go well as well.

Yeah, thank you very much. Thanks for having me. And it was an awesome conversation. I've really enjoyed it. Thank you. Um, if people want to check out code speak or they want to check out anything else you might be involved in, where can they go? So Codespeak.dev, we hopefully will be updating the website. Again, I don't know when this podcast is going live. But we'll be, yeah. So maybe by that time we actually will have updated the website. Yeah, so in any case, cotspeak.dev is your primary source of information.

You can subscribe to a newsletter. You can try some things online. You can download some things today. Maybe in two weeks, there will be something else to download. But in any case, you can play with everything there, Codespeak to Dev. You can also join our Discord. And actually, at Codespeak. Dev, we have this thing that's called Intent Recovery Tool or Intent Studio, even, where you can play with this idea of extracting intent from your agent sessions.

So you can upload your sessions and will give you, like a set of requirements, we'll give you a spec document that were reconstructed from your conversations with agents. And this is like this intermediate version, that's not perfect yet, but you will get something. You can use it as a baseline working in your project. You can use it with agents just to make them a little more aware of what you're building here.

And with time, we'll add features to that and we'll update live and so on so forth. So yeah, well, you're all welcome to try this and give us feedback on Discord about the features you like and features you want us to add. Um, nothing else to mention. Well, there's a lot to mention, but I think we're good for now. Okay, okay, fair enough.

Um, I guess I do my outro and then we'll sign off. Right. Thank you. Uh, my main channel is Brody Robinson. I do Linux videos there six-ish days a week. Uh, check that out. You'll see some neat things there. I've got some, uh, fun ideas.

I'm going to go buy a Nvidia GT 710 and see what we can do. That's $35 GPU. you. We can do a lot with that. No. No, we cannot. I've got the gaming channel, Rodeon Games. Right now, I'm streaming Like a Dragon and Shenry 3. And if watching the video version, this, you can find the audio version of basically every podcast platform at Tech Over T.

And the video on YouTube, Tech Over T. We also have a Spotify video as well. I'll give you the final word. How do you want to sign us off? Well, the world is changing. It's up to us. we fit in the new version of it. And I hope we all have fun upgrading our skills

and figuring out how to live in this upcoming world that's being created with our active participation. Good luck everyone. Okay.