What does code mean in 2026?

Speaker A: Foreign. Welcome to the ThoughtWorks Technology Podcast. My name is Alexei. I am one of your regular hosts and I'm speaking to you from Sao Paulo in Brazil. And this time around we'll have a chat with Unmesh Joshi. Hello Unmesh.

Speaker B: Hi Alexei. Good to be here.

Speaker A: Perhaps I'd better let you introduce yourself instead of me trying to tell people who you are.

Speaker B: Yeah, so uh, I'm a distinguished Engineer uh, at ThoughtWorks and I spend a lot of time exploring coding and ah, impact of LLM, um, on coding while I write a lot of code.

Speaker A: Excellent, excellent. Uh, it's great to have you with us today and thank you so much for joining us. Um, the topic today is uh, actually talking a little bit about what is code. So uh, an article of yours came out this Last May on MartinFowler.com um and we'll sure have a link to uh, it in the show notes for listeners who haven't had a chance to look at it yet, uh, let's try to explore a little bit about that. These days uh, there's a lot of conversation about tooling new development paradigms, methods, how do LLMs and the new advances change the way we develop, uh, how we build uh, harnesses around uh, the code we are writing and validations and all those kinds of things. Uh, and even some of those conversations go in the way of Code is not a commodity. Coding is solved. So what made you go back to that most fundamental definition and question, uh, right now at this moment. Unmesh. Maybe, maybe let's get a little bit of the why, uh, thinking uh, about those kinds of things.

Speaker B: Yeah, absolutely. Uh, and as you rightly said, more and more people think nowadays that code is commodity and uh, rightly so because you see writing uh, just like a few lines prompt and getting a whole system running, uh, for you. For last several years I'd been working on distributed systems and doing workshops and even consulting around distributed systems and also writing uh, uh, a lot of code around that. Um, and obviously uh, with LLMs and tools like color code and codecs, um, and anti gravity and cursor and others, I uh, obviously used a lot of them um, uh, while writing the code that I had to. And I um, see that uh, a lot of discussions happening on social media and around uh, the perception that's formed is uh, uh, that code is just a syntax, uh in a particular programming language, uh, that uh, gets compiled and get built into an application. I think uh, the point that before you write even first line of code, uh, there is A lot of context that built uh in your head, uh, and that's important. I mean starting from understanding the broader context of the problem that you are trying to solve and how you're going to structure the solution. And uh, a lot of that uh, is very difficult to get right up front. So you need to uh, iterate uh over uh what you are trying to build, um, and that what we call call as coding um activity. Uh, uh. It's uh, part of the whole process of trying to understand the problem and building solution. Um, and all that still needs to happen even when uh, maybe you are trying to describe um, uh something to an LLM, um, and you still need to structure your thoughts, you still need to um, uh think how you're going to structure the solution, um, and then maybe maybe drive uh, or iterate or let LLM iterate over it. Uh so I experienced that while building. I mean even if uh, I think distributed systems is not something that uh, everyone builds uh, every day. So it's kind of a niche topic. But I think it helped surface these issues more, more prominently uh, because the topic is so difficult. Uh, and I think uh, that's true even in any regular uh, um coding assignments we do, uh, for any of the business domains.

Speaker A: And I think everyone who has developed an application, a system or whatever can relate to this. Uh, the thinking process is intertwined to coding and even the way we express it. So uh, I think, I think that's easily relatable. So when uh, you start thinking about concepts, but then once you start making them more concrete, you get a new understanding of your own thinking and uh, what do the abstractions mean and those kind of things. So that is interesting and I wanted to go back to one thing you highlight in your article that I think is a key idea. Because when we think about you know, this, even this commoditization process, I think people are looking at the instructions. Oh, this is just machine instructions. Something that needs to be executable, right, or executed uh, by a machine. But in the article you make, you talk about two lenses of or two ways of looking at code, right? Instructions but also connected to this thinking process. So maybe you can elaborate a little bit on that and talk about this definition.

Speaker B: Yeah, I mean two lenses that I talk about in the article. One is uh, obviously what everyone thinks code is that you are telling a computer or a machine what to do. Um, but there is another important uh, aspect of code and that's structuring your solution. Uh, and in doing that, uh, expressing your understanding of of the problem as well as the solution. Uh, you are trying to build, uh, and I think all the high level languages uh provide uh, you the mechanism uh to do that. Object oriented languages, uh, allow you to um, think of your problem and solution in terms of objects and functional languages allow you to uh, do that um, as a composition of functions. One of the other aspects um, is that a lot of times nowadays people think that uh, uh, if you just know English, because English is the new programming language. I mean that's a very popular theme nowadays. Uh, but it's not correct to think that way I think because English uh, I consider uh more as a carrier syntax. Uh, uh. I mean just so that you understand when I uh use some words and construct sentences out of those words, uh, you, you make sense of uh, that. But um. But when I uh. When let's say I talk about uh a consensus protocol using majority quorum mechanism and uh, and maybe sometimes using quorum overlap, uh and uses a uh concept of a term or a ballot, um and stable storage, uh now the words that I used in here, uh, someone who is not uh, uh, someone who doesn't understand distributed systems and what this consensus is all about, uh, it's very hard for that person to um, uh know what I'm talking about. Uh, or even if you take simpler uh examples uh of let's say web talk in English about uh the verbs, uh get post put, uh and uh. We talk about idempotency, uh characteristic of put or using caching effectively for get. Uh all the words that we are using there. Uh, they have a very specific uh meaning uh um in those particular technical domains. And uh, when we say that uh you can um, describe your intent in English, uh one of the important aspects uh, that's often missed is that's possible only if you understand the concepts uh very deeply, uh of what you are trying to do. That aspect is very, very very very important.

Speaker A: Yeah, absolutely. I think, I guess that's why mathematics had to. Mathematics doesn't get created in English, right? Or in uh, those carrier languages as you say. So you need a more precise way of expressing things. Uh, you made me think of uh. Years ago I worked with a retailer. Uh, it was a data project. So talking uh, about the data architecture and these kinds of things and the work we did made them realize that they had three or four different definitions for inventory or the word and uh, depending on specific context, specific use and those kinds of things, um, uh, and were very different things. Uh so I guess uh, that level of precision and trying to uh, convey that idea. Uh, the code does help you make that concrete. Right. The other thing is formulas. I remember years ago working on financial calculations formulas and we thought we understood the algorithm when we were talking about that in our case in Portuguese. But then when we sat down to write the tests and write the code, we would understand that, hey actually we got it completely wrong. So uh, that's an interesting process.

Speaker B: Yeah. And it's really interesting how uh. How a lot of times syntax of uh, doing something and concepts of that particular uh topic, uh uh, there is a correlation uh a lot of times. So for example, uh, if you're trying to parse something with uh, a regular grammar, uh, you need to understand regular expressions. Uh and regular uh, expression syntax is um, is very hard for a lot of people. I mean I found it very hard to remember.

Speaker A: Me too.

Speaker B: Yeah, yeah. But if you understand the concepts uh, uh behind that uh, then I think LLMs are, I mean they cut through uh all the syntax noise, uh uh, of a particular tool that you use uh for regular expressions. Uh, but understanding those concepts I think is very important. And other thing that uh, I found often miss but is very important is we all know domain driven design and it's very popular but the concept of ubiquitous language, uh, that domain driven design talks about, um, uh, I think uh, it's an extremely important concept. Um, and a lot of times uh, what we call as act of coding is about building that ubiquitous language. Uh like whether you do it intentionally or unintentionally, uh, uh, whenever you work for domains like let's say retail or finance or commodity trading, uh, or any of that, uh, and you write software for that, uh, uh, in whatever programming language uh you are using, uh, you need to choose words for naming methods and naming classes, naming modules, uh, uh, your APIs and so on and so forth. Um, and you can't just choose random words, uh, when you name those things, um, the words they come to you based on all the discussions that you have with, with your stakeholders, with domain experts. And there is another important uh, I think interesting concept that uh, I see is uh, uh this ubiquitous language. Uh, it's like building a shared vocabulary, right? I mean you use like inventory example that you, that you talked about. Uh, in any domain there are, there are so many words uh to name the concepts. Um and uh, I think I take uh, it back to uh, a fantastic uh keynote at Oopsla, uh, that guy Steele gave uh, in 1998 oopsla conference, um, and he was talking about what uh constructs a programming language should provide um uh. Uh, to be able to construct vocabulary. Uh and uh. The way he described programming uh is an act of vocabulary building. Uh and that's exactly uh what we do. And a lot of times um, what happens is that the power of higher uh level programming languages, uh, which is essentially um, allowing you to build this vocabulary, um if you just use a higher level programming language. Um, we talked about like two aspects of code and the basic is instructing the machine, uh, and if we just use a higher level programming language, uh, uh, in a way to just instruct the machine but not, not uh. Not use its power to create the vocabulary. I think, I think that's where all the problems uh in. In. In programming um start uh, start showing up. Um, and another useful thing, uh, uh that I see, I mean when I work with any client, uh, you see that even when we say very well established broader domains like uh, uh, let's say banking, uh or retail, um, uh which have online presence for several decades and uh, very mature um software systems, uh, built for decades, right? 20, 30 years, um you still see that uh, when you think of it uh as uh a software, as a vocabulary building. Each bank, uh, and each business there is a broader vocabulary of course of banking as a broader domain. But there are dialects like uh. Every bank, uh, every retailer will have their own variations uh of those things. And it's fascinating, right, because even when we say English as a language, for uh example that's true for any spoken language as well. Uh, in India where I believe uh practically every 100 uh kilometers, uh there's a different dialect, uh and uh, every 500 kilometers it's totally different language. Uh and uh. And it's important, right? I mean you uh. When, when uh. You need to understand importance of those, those variations and those dialects. Um. And I think that is one of the reasons as well that uh. There is no universal product that uh. That and there is no universal vocabulary for uh any particular domain. And other very interesting aspect of it uh. I think is that that this vocabulary, it always gets built on the, on the intersection of technology use and the business domain for which you are building uh, building software, right? Because uh. There is, there is no meaning for inventory. I mean there is a meaning for inventory. But uh, when you say that inventory uh getting represented for, for retail on the web, there are web specific aspects that you need to deal with while representing that inventory and while working uh, with that inventory, right? So understanding that intersection, um, and then building that vocabulary at that Intersection, uh uh is important and that also builds I think uh. I'm not sure if I'm running ahead of the questions that you are going to ask.

Speaker A: No problem.

Speaker B: That vocabulary also forms uh the conceptual model, uh like it's a shared conceptual model that uh, you share with your team. Um and having a shared conceptual model is uh, extremely important because uh, it allows you to read between the lines. Uh because whenever you communicate uh communication uh it's very difficult to communicate precisely even when uh, I mean even when two people are talking to each other in uh like uh uh uh face to face, uh even then you, you take cues from facial expressions, you take cues from uh maybe, maybe uh some of the movements, hand movements that I'm doing. And having that shared conceptual model uh helps you uh read between the lines uh when you, when you speak about something. And same is true when you code, uh having that shared conception model helps you code as per the expectations uh, uh that you have from your stakeholders. And with LLMs particularly, uh, I think it's extremely important to have that shared uh conceptual model because LLMs are trained on the entire Internet uh of data. So when I say I want to build a web API for example, uh or I say I want to build uh a consensus algorithm which I do a lot while teaching distributed uh systems there are so many variations and uh, so many uh decisions that you really need to take. And uh, LLM probably will take a lot of them and a lot of them that you really don't want it that way. And that's where I think uh people talk a lot about uh context engineering and building harness around uh the code that's generated by LLMs to make sure that you steer LLM in the right direction. But if you think of code as the conceptual model which feeds into the vocabulary uh that uh, that LLM uses, um, it becomes um, I think extremely powerful because then your code itself acts as a fantastic context as well as harness um for your LLM. Um and I think all this uh, it's fascinating how uh like uh this concept of vocabulary building and domain driven design, uh and now how LLMs, um uh how you are like seeing uh it again uh in the context of LLMs, that all these concepts uh, they really help you. I find it uh, very fascinating.

Speaker A: Yeah, absolutely. So I think you nailed it when you mentioned this conceptual model that needs to be shared right in the team as well. Uh and then what are the tools that you have for building this because you know, natural languages like English, uh, Spanish, Portuguese, et CETERA they're not very precise. They're not good tools for building those kinds of things. And so you mentioned uh, Guy Steele's uh keynote about uh the tools that higher languages have for building those kinds of things. I mean when you think about for example object orientation it forces you to think about you know, hierarchy of concepts, interactions, uh, communications and uh. And I think everyone who has developed bigger applications can, can draw from their experiences. Hey, I finally understood what I meant by that concept when I tried to feed that you know, into um, a communication structure among uh, different objects or uh, when I had to uh, you know, think about inheritance and how these things correlate to each other and those kinds of things. Um, the same with functional programming for example when you, you know, what are transformations that the data needs to go through, ah, from a functions application perspective. So uh, those ways of thinking, uh, they help us build that model in a way that's better expressible as well and more precise. Right, because, and then that helps with uh, communicating not only to the machine but uh, among team members and even to LLMs, as you say so.

Speaker B: No, absolutely. And I found it uh again and again, uh, even when working with LLMs, that programming paradigms, uh as you rightly said and even going beyond uh programming languages, there are programming paradigms which are broader. Uh, I think when uh you say object oriented or functional and they help you uh in your thinking. Uh a lot of times uh, when I was building a small framework that I uh use for teaching distributed systems, I mean I was doing it in Java but a lot of it I did, some of it I did with uh enclosure, uh and some of uh it I did in Kotlin and some of it I did in Golang, um, uh and it was helpful uh, for example when I define a generic model uh that I want to use for constructing distributed systems, I I think of a process and I think of messages and network and storage, uh, and when I represent those as objects, uh while doing that coding, I mean just because I am well versed with let's say object oriented uh paradigm it shapes up my thinking uh, about how I'm going to represent a uh process uh as an object, uh in code, uh and same is true with functional. When I'm using closure, um uh and I'm doing a chain of uh, uh processes or a set of data. If I know functional programming and I know how method chaining for example works it helps uh, because I can definitely not do uh, if I just uh, stick to Java, uh, and uh, pure Object orientation, uh and that's the reason you see uh, um uh all the programming languages they eventually become what you can call as multi paradigm languages, right? Uh because Java, which started just as pure object oriented uh language it has a lot of functional uh programming features uh nowadays and it's important to realize that uh the programming paradigms um, and even sometimes languages uh, they help you. And I also find it fascinating that whenever we uh talk of programming vocabulary um uh and shared conceptual model uh, there is also place for well understood idioms and patterns. And uh, I see that uh when we talk of programming languages or paradigms there is a well established community around it. Uh and whenever you have well established community uh there are some shared idioms uh, well understood within that community. So uh, Java is object oriented but uh, when you code in Java uh there are some well understood idioms uh of how to do certain things in Java, uh, or when you do functional programming. There are well established idioms uh in functional programming and if you're doing say rust or golang, um, there are some well established idioms uh in those communities uh and it's useful um to understand uh, and know those idioms and uh, even when you are working with LLMs, I have found that uh, they help me uh a great deal uh uh uh, because I can steer LLM using right words uh uh in my specs.

Speaker A: Yeah it's interesting and goes back to what you're saying, right? Because when you think about those idioms they, they will bridge the conceptual understanding of the business that we have for that particular system to uh, the common knowledge around the technology that's being used uh that many times materialize in idioms and then how does you know that connection between the business concepts and the technology implementation for doing what needs to be done needs to happen. So that is quite interesting. Ulmesh, I also wanted to touch on a topic uh you have published about that connects to all of this. So when we talk about building that model that goes back to understanding what is it that we're building, right? And the model does help a lot with that, uh not only understanding the business problem and the solution that we're building but also that understanding of the technology solution that we're deploying uh, and code definitely will serve that role of uh, uh being uh the tool for that understanding and that knowledge. Um so you have also talked about how important it is uh for teams to keep that understanding uh and that and that learning both from uh a you know, application development perspective but also from a more Technical perspective. So how do you see that, that connection?

Speaker B: Oh no, absolutely, absolutely, absolutely. And I think uh, it has come back to me again and again because uh, in software you know that every, every few years you build like another layer of abstraction. I like to see abstraction, uh, in a way. I think it was, um. It's uh, a sentence from a very nice book on organizational patterns. It talks about why uh, architects need to code. Uh, but uh, it says that abstraction, um, is a controlled form of ignorance because you are intentionally ignoring certain details, uh, so that you can focus on certain aspects, uh, of your thinking. But uh, it's extremely important to understand what you are ignoring, uh, while thinking. Because even when, uh, you have layers and layers of abstractions, uh, and with cloud you can almost cloud and containers and all the other things, layers on top of physical machines, um, a lot of times you ignore that, uh, there is a physical world that exists, uh, which runs on actual power. Uh, there is something called a cpu, uh, and there is something called as memory, um, which is volatile in nature. And uh, any data that you store there goes off, uh, if there is no power, uh, and then there is network. And uh, when there is network, uh, there are physical distances that your message needs to travel, um, and then there is physical limit of speed of light on anything that travels, um, in a medium. And then there are storages and uh, storing anything is the slowest operation, uh, that you need to do. And again, while I was working on distributed systems, I found this fascinating uh, book, uh, called Understanding, uh, Software Dynamics. Uh, it's written by a veteran Googler. One of the things it starts with, uh, is that uh, there are only four fundamental physical components that uh, you need to really understand. And it's cpu, memory, uh, disk and network. And um, even when there are layers of abstractions, if you don't understand what's happening at the network and CPU and memory and storage level, uh, it comes and bites you, understanding from that level to the layers above and layers above and layers, uh, for any professional software developer or architect, uh, it's important, uh, because I think the more you understand when to ignore details and when to care about details that are hidden by all these layers, uh, I think that that's directly proportional to how successful or unsuccessful you are with what you are trying to build.

Speaker A: Yeah, absolutely. But you need to choose, right? Because abstraction is weak. And every now and then we need to go down layers of abstraction, uh, to fix things or understand what's happening or why the system is behaving in a specific Way. Another example you mentioned in a previous conversation we had is, is about platforms. Right? So we have seen a uh, similar situation in which uh teams add more tools, co generation abstractions, other things without understanding what's really happening and that that will just bring a lot of variation or entropy to the teams and uh, coordination problems and those kinds of things. Right.

Speaker B: So no, absolutely. And I think code, uh a lot of focus nowadays is on uh talking about generating code. But uh, there are a lot of things outside of code which actually matter and they matter more. And um, uh I'm seeing that uh, with lot of uh platforms uh, uh that become complex over time uh because uh, when you build a platform um and a platform that caters to a particular business, uh let's say a retail or, or trading or banking, uh the expectation um, is that a uh lot of teams should be able to reuse uh what is common uh and quickly able to build something on top of that platform. Uh but things like uh Conway's Law and they become more important than the actual code that you ship, uh and Conway's Law, uh because the way you structure your teams, whether you like it or not impact how your code shifts uh over time. Uh and there is always this tension uh I see uh with platforms and uh. The bigger the organization, the way you structure your teams because they really um uh are driven by how those teams are funded. And then once you structure teams in a particular way and a classic tension whether if you, if you uh always form teams um uh based on the functionality that you are trying to build, then who owns the common platform and libraries and if you form the teams based on the common components then how do you structure the teams who serve a particular function? And there is always a common uh tension in that uh and these decisions they define uh, or decide how you factor uh your entire functionality into components and services and how they talk to each other, how they depend on each other and all the complexity uh of software that gets built um lies in there not really with the code. All these decisions uh, which are higher level decisions I would say uh, which uh, which finally decide uh how your code looks. Uh but these are the layers at which uh the complexity lies. And uh. I think there is no easy answer to this uh because uh real life is complex. It's I think a mistake to trivialize that a lot of times because uh, a lot of times what happens uh in the world of software is that whenever a new shiny tool comes up uh, it's very easy to think that that's an answer to every complexity and every problem that uh, that we have in life. But that's not, that's not the thing because it's not that easy to go back to Fred Brooks, um, the classic mythical man and uh, he talks of complexity at two levels, right? He says that uh, there is essential complexity, um and uh, there is accidental complexity. And any tool or uh, solution that you, that you choose, uh, the focus should be to reduce the accidental complexity that's introduced because of a particular technology or a particular uh, tool or a framework that you have. But you need to acknowledge uh, essential complexity, uh, that that's part of your business or parts of the domain that uh, that you are trying to build, um, like while building distributed systems, uh, that uh, that I work a lot with. When you talk of consensus algorithms, uh, I mean they are complex. I mean I can't trivialize that saying that uh, okay, if I use a particular tool or a particular method, building uh, consensus algorithm is going to become easy. Uh, it's not. But the focus should be to uh, try to reduce that accidental complexity that comes in my way because of a particular tool. But, but acknowledge that. Okay? I need to really take effort to understand uh, why consensus algorithms are built the way they are and um, uh, why they are implemented the way they are. Uh, and uh, I think it's equally important in any domain, uh, any business domain. Right?

Speaker A: Yeah, absolutely. And that will require that understanding and having made a good choice of what to abstract and what to ignore and what not to ignore. Right. So goes back to what you're saying.

Speaker B: Absolutely.

Speaker A: And unmesh, how about the future? So I mean because uh, on the other hand there is a lot of uh, you know, as we were discussing LLMs, to help a lot with understanding details that maybe we don't need to know exactly or we can invoke them. You uh, know just in time, like knowing specific idiom or knowing specific syntax. Um, there is also a lot of boilerplate instructions that usually need to be generated and maintained and those kinds of things. And we have seen LLMs help a lot with that. So um, I wanted to ask you maybe what are some of the things we're working on? Is it possible to work at a different level of abstraction? Or uh, how specifically uh, do you see uh, you know, advancements with the use of LLMs, uh, combined with those ideas, uh, or maybe what are you working on connected to this?

Speaker B: Yeah, so currently what I'm fascinated about and um, actually um, working uh, on is uh, using domain specific languages, uh, with LLMs I'm fascinated because uh LLMs accelerate what M. I'm doing um Domain specific Languages. Uh we all know, I mean there is a very famous book written on this and there is a lot of discussion uh about domain specific languages. But what I see particularly with LLMs, um is that uh all the LLMs are as effective uh as I would say the quality of the context that you build and the quality of the harness uh uh which quickly identifies if there are uh. LLM is divergent from uh what's intended and that expressing that intent uh in the way you prepare context for the LLM as well as the uh harness for uh finding the deviations that can. Very beautifully done uh with domain specific languages because domain specific languages when you use certain words uh. And again it. It goes back to the vocabulary discussion that we had. But uh. With DSLs there are uh. There is a very. The state space of uh how you can arrange those words and what you can do um uh. Uh with those is constrained. And that I think works uh very well with uh LLMs because uh you don't ask LLM for example to generate uh a Java program um uh or a web application. You can give some examples and it's uh sometimes called as a few short prompting uh kind of thing that you give some examples of how your domain specific language um uh uh works uh and then prompt it uh to then generate uh code in that domain specific languages. Um that I think. I mean I've not used it uh on the large scale projects but whatever work that I do I found very uh good success with uh that. So probably the future uh and it's very very difficult to predict but probably uh the future is having more and more this DSLS, um uh to orchestrate working with LLMs.

Speaker A: That's fascinating. So we'll be watching closely your future thoughts and experiments on that. All right, so we're almost at the end of the episode. Unmesh. Any final thoughts you would like to share? Maybe. I mean we talk a lot about some of the fundamentals of uh. The role cold plays in development, understanding and those kinds of things. Maybe what are some of the principles that will hold even you know uh in the current big uh change scenario that you have for the industry or any advice you want to give people or any. Any final thoughts?

Speaker B: I think sometime back we. We published an article uh uh titled Expert Generalists and uh, and the characteristics of uh that Expert General is Persona. Uh and. And we find a lot of those. I mean the article was written based on experience we had with our Thoughtworks colleagues. Uh, but, but all the characteristics of um, that expert generalist Persona, uh, I think uh, it's uh, going to thrive in the LLM era. Like uh, just being curious and um, understanding the fundamentals well and uh, not limiting yourself to a particular domain. I mean all those characteristics, uh, I think uh, they are going to be essential I would say uh, in the, in the future.

Speaker A: All right, thank you so much. Thank you so much for that. Uh, okay. And that, that, that brings us to, to the end of the episode. Unmesh. Thank you very much. It was a great conversation. A um, great pleasure to have you uh, with us. And for all of the listeners, thank you so much for joining.

Speaker B: Thank you. Thank you for hosting me again.

Speaker A: Sa.

Speaker B: Mhm.