Building Context and Future Skillsets

I got some feedback recently in the Developer T Discord community. If you're not a part of that, you can join at developer T.com slash Discord. Uh but we're not trying to do an ad. I got some feedback asking me if I intentionally was trying to cause uh a flame war. Um you know to to have an overblown opinion, foregone conclusion that gentic coding would be the future. And that we should just kind of assume that going forward . And I want to address that. I also want to talk today uh I'm gonna I'm gonna give some speci fic advice to you 'cause the same person asked, you know, what what are some skills, uh assuming that is true, that that agentic coding is the future for the for the industry, what are some skills that that we can build, that we can reasonably depend on, that we can build reliably? And we've talked a little bit about that since that episode . Uh we've talked about some skill building that is more durable um in the face of this revolution. But let's let's first talk about why am I talking about this stuff the way that I am? Why am I uh you know uh why why have I kind of just accepted this ? And there's a couple of reasons. There's some very practical, simple reasons . Um, the first is that I've used it myself, I've seen how useful and powerful it is. I've seen that it's extremely unlikely, extremely unlikely that the industry rolls back away from this . And certainly with as many different companies and as many different routes to using this technol ogy , it's unlikely that any one particular failure or pricing model is going to cause the industry to reject this direction either . And so the premise that you'd have to accept, if you run a simulation in your mind if you try to imagine a future, try to imagine a future where agentic coding has disappeared. All right, we're going to take it to an extreme and then we can kind of learn from that extreme. Try to imagine a future where agentic coding has disappeared and our workflows look a lot like they did, let's say, in June of 2023. Just kind of picking a random date here, but June of 202 3, we didn't have the same level of assistance that we would have. We could kind of treat AI, LLM-based, uh, you know, generated tokens, etc. We could treat that as um something that answers questions, essentially, right ? But it's not uh you know, it we're we we reject the idea of tool use, we reject the idea of context and spec driven development and all of these new techniques that probably by the time you listen to this, if you're listening in a couple of months, even what I'm saying is going to sound a little bit out of date because these things are moving quickly. So the premiseise, the prem that we'd have to accept , if we imagine that we're going back to all of that, is that somehow we collectively uhh we have some experience, we have some uh kind of um you know, shift in the collective consciousness about how to move forward , about all of our tooling, etc. And all of the signals and all of the data that I have, both anecdotal and real data point to this increasing in adoption, this increasing in effect that it's going to have on the software engineering community . And so in the face of all this information , I can either continue to again uh running those simulations what does the future of this of this show look like if I uh you know don't face those realities ? If I don't talk about agentic coding, if I don't talk about the impact of AI, if I don't talk about how to build skills in this new kind of emerging environment , uh Um then this show becomes less useful to you in your career . This show becomes less accurate. It becomes a less accurate picture of reality . So no, I'm I'm not trying to t sort of flame more . Um the kind of attention that I want to get for the show is not the flash in the pan quick click. Show's been around for over a decade now . So we've kind of gotten past that . Instead, what I want to do is I want to help equip you to actually go into the industry with new mental models, with n a new perspective, with uh the right um kind of inform ation to succeed . Right ? And so whatever your people's misgivings are about AI, whatever their concerns are from an ethical perspective, uh you know f from a skill development perspective I, totally respect . Um I I I really do truly respect that people have their own perspective on this because it is complex and I don't want to simplify that , or oversimplify it rather. I do probably want to simplify some of this because if we try to get into the complexities of all of it, um then we won't be practically useful, which is really the goal of the show. It's really my goal on the sho w is to be actually practically useful. That you can take what we talk about and apply it as soon as possible. Right ? And and we try to avoid getting into practical uh advice when it comes to actual implementation detail, right? In other words, I'm not gonna uh you know tell you what design pattern to use uh on this show, right? I I want to approach this from practically applicable models, mental models and skills in the light of what's happening in the industry. Right? Okay . So with that in mind, with that kind of premise , uh I'm going to talk a little bit more today about building skills and in particular i want to talk about something that will continue to be important um especially as you become more and more senior and as you're using these tools , uh a kind of principle that you can carry with you that will continue to become more and more important as we take advantage of uh of the power that LLMs are currently generating in the industry, but also this this works outside the skill that we're going to talk about today. It works outside um you know uh of of the this is not a specific skill that you're gonna use just with your agent coding. We're not talking about the uh uh you know the the new oh there's new something new that came out a couple weeks ago, the caveman coding or whatever it's called, um, where you try to save tokens by speaking in in uh you know caveman-esque language. That's not the kind of uh skill we're d gonna talk about. We're gonna talk about one uh a skill that is transferable in a human environment as well . Uh part of the feedback I got is that just as I got on a roll, uh uh I jumped to an ad break. And we're gonna do that again. And part of the reason for that is because we wouldn't be able to do the show if we didn't have sponsors. So we're gonna talk about today's sponsor. This episode is sponsored by GetUmblocked . Uh getUmblocked.com. The name of the company's unblocked. Uh your coding agents have access to your code base and probably more . And uh maybe you've connected other tools, uh MCPs, skills, whatever, right? Things that that can call out and try to gain context, but it's not easy to keep up with all of those uh skills. In fact, since I got this ad read, I've had to rethink about what's even in this ad read and whether it actually matches up with reality in terms of all the different ways that you can connect your LLM to your environment. But this access that you can currently provide doesn't necessarily mean context. Agents can't really reason very well across MCPs on their own and they don't know your architecture decisions. They don't know your team's patterns or why the API was shaped the way it is. You have a lot of valuable document ation. You have a lot of decisions that have been made that are valuable that if you were just talking to a senior engineer, they would point you to those sources, right? But agents tend to look in the wrong place. They don't really know what is uh you know uh highly reliable versus less reliable. They don't know who wrote what. Um and so you're gonna spend your time correcting the agent and reminding them that that particular piece of documentation is kind of out of date or it's not quite right. That person wrote that just kind of in their free time. It wasn't really accurate to begin with, right? Unblocked is the context layer that your agents are missing. It synthesizes your PRs, your docs, your Slack messages, and Jira issues into organizational context that agents actually understand. So they make better plans, they write higher quality code, they use fewer tokens, and they require fewer correction loops. If you're running Clog Code or Cursor or Codex or any agentic workflow, unblocked is certainly worth a quick look. You can get a free three-week trial at getunblocked.com/slash developer t. That's g-e-t-unblocked.com/slash developer t. Thank you again to unblocked for sponsoring today's episode of Developer T. I want to teach you this skill, or I I guess uh point you to this skill. It's not something that I can teach you in this um in the short podcast . Instead, this is this is a skill built off of principle. So I want to talk about the principle today . Um and this is inspired by a handful of stories that you've probably read or something . They provide the single prompt and and then they get uh something that is close to at parity with a very complex uh piece of software. Right. A good example is Minecraft . And so uh we look at that and and there's something to learn from it . Right, there's something to learn from it's not that they chose you know some special structure for their prompt. I'm sure the structure was fine . But that's unlikely to provide in a single prompt, just the structure being correct, is unlikely to provide that kind of extraordinary output . And so if you think about what the prompt was the content of these prompts . Again, we're not gonna get into prompt hacking, that's not really the the point of this episode . Instead, I want to look at a fundamental kind of principle here that's replicated by the way in studies that have nothing to do with LLMs. Okay . The principle is high context or high meaning abstraction . High meaning, or uh uh you know, this is meaning rich is another way to put it . Meaning rich abstraction . Okay. What does this mean? What is it what does it mean to have meaning rich abstraction? If I told you that um I want you to build Minecraft , if you have played Minecraft, then in one word, Word Minecraft in this case, I've communicated uh you know perhaps two or three chapters worth of a sp uh specification to you . Depending on how much, and this is a really critical component, how much you know about Minecraft , whatever you know about Minecraft, I am now communicating to you based on your knowledge. So you can think about it like almost like a pointer that I'm choosing. It's a uh a very rough, non-deterministic pointer because I don't know exactly how much you know about Minecraft. I know what Minecraft is, right? I in this case. I I know uh let's say I'm I'm asking for Minecraft. Uh there may be some intent, something that I know, there may be things that I don't know about Minecraft, but I know that it is meaning rich. In other words , again, in in a single word, I've communicated a lot of meaning. Now it's very important to recognize that I could communicate a lot more meaning in tot al with the word let's say human history . Well human history is encompasses everything that we know about humans, so it also encompasses Minecraft . The critical principle here is not just a meaning-rich word , but it's also one that is specific enough that the variability of that word or what it means is redu ced to make it useful . In this case, Minecraft has a specific kind of set of information. If I were instead to say I'd say a uh a block building game , then maybe your mind will pull up Minecraft. Certainly if you were uh let's talk about LLMs for a second. If uh if the LLM is using some kind of rag or uh you know vector space to to determine whether that word is is what what it's close to, certainly Minecraft would be nearby in that vector space . And so if I said a block building thing, then I would, you know, you would certainly have uh similar conjurations. There would be something that triggers in your mind, probably close to Minecraft, but there's certainly things that Minecraft communicates, that block building uh game does not communicate. Alright, so by choosing the word Minecraft, I'm more specific, but still meaning-rich. Think about it like a graph, right ? Um the bottom of the graph is specificity and on the on the y axis, so on the x axis, then on the y axis uh you have uh uh meaning ri ch, right? Um contextually meaning rich . And as we begin to build software with agentic patterns , this is one area where your experience and your knowledge as a software engineer, as a software architect, as a data engineer, as an ML scientist, whatever your role is , okay , your vocabulary , especially in the top right of that graph, so in other words, in something that is both meaning-rich . And speci fic . Meaning rich and specific. Your ability to communicate in that area is going to give you drastically better results in your agentic coding efforts. I'll give you a very simple example that I that I thought of when coming up with this with the idea for this episode. And it's based on some of my some of my own experiences um in in play ing with the various uh various patterns that we are afforded by Clog Code and and other tools like it . so i was thinking about some authorization rules right in in my in my project and i know i happen to know how a handful of patterns for doing authoriz ation rules. You can have something like a pipeline pattern, for example, where you have to pass one and then you pass the next and then you pass and something gets handed between those steps. And that that didn't feel quite right. We don't necessarily need to hand something between the steps. Maybe we don't necessarily want it to be uh a a single graph structure, right? Like a like a directed graph or like uh you know blocking processes. Maybe we want to run all of those in parallel or some of them in parallel . So a pipeline wasn't quite right, but I I knew about another idea called a strategy . And in this case is you know a strategy might be doing the same step, but with multiple ways of accomplishing that particular step. And the abstraction of the strategy, right , um allows you to kind of treat all strategies the same. Right? Strategy in this case, just in case you're not familiar with this word , uh the you know, the the kind of meaning-rich and specific term here is a strategy pattern . Strategy pattern. So instead of having to describe to the LLM exactly how to implement a strategy pattern , where I explain that you have multi ple classes and each class has a similar interface. So they all maybe they all inherit from a parent kind of a base class for the strategy. And then you have specific implementation details held inside of each strategy . Okay, I I don't want to explain all of that. It takes time, it takes effort, kind of defeats the purpose. Might as well write it myself if I'm gonna have to do all of that. But if I know, if I know the vocabulary , right? If I if I've learned about strategy patterns and when they're useful, what what to do with that , uh then I can dip I can employ that language in my prompting ? Which is exactly what I did, by the way. And it worked exactly the way I wanted it to . The key insight here is to pay close attention to the meaning rich concepts, the mental models, the patterns, the abstraction layers that help you talk about what you mean . This layer that sits above the work that you're doing . The kind of one layer up this uh way of doing something like a pattern, for example , meaning rich concepts like understanding how another team may have implemented a particular pattern or set of patterns. You could abstract it beyond patterns into uh you know a named thing, right? Um something that uh maybe somebody else has implemented that has published a paper on that implementation. We see this all the time with certain kinds of algorithms. Another very common example of this is is tech niques, mathematical techniques. So for for for example, uh doing certain distance algorithms have a name, and that name kind of implies the um the implementation detail . A good example of this is is Monte Carlo. If you're not familiar with Monte Carlo forecasting, it's a basic frequent uh you know frequentist kind of um way of forecasting you use samples from past data and you build up new samples into the future if you know what Monte Carlo is , if you have awareness of of what that language means, that's a high specificity, high uh uh uh sorry, uh meaning-rich abstraction . Right? Okay . So as you're working on trying to build your skills as a software engineer, this is where your knowledge, your domain knowledge, continu es to be use ful . You can also learn back and forth about new patterns. If you know about one pattern and you're not sure if it fits, this is where you can have, you know, for example, a conversation with another engineer, um, a more senior engineer, you can have a conversation with an LLM or with both , and poke around on learning about new patterns, learning about new strategies, gaining new vocabulary . Having a new piece of vocabulary has been shown, and again this is before LLMs, has been shown to create fundamentally new meaning for people . Right? There's certain languages, for example, that have word s for things that don't necessarily exist in other languages. And that changes parts of their society. It changes the way they think, and it gives them a way of communicating with other people , an idea that they can't communicate as succinctly without it Similarly, we gain uh conceptual vocabulary when we gain experience . And this is really the thrust of my argument here is that your goal in protecting your value, right? This is a huge uh concern amongst engineers, protecting your value as an engineer , a huge part of that , a huge part of that comes down to simply uh gaining making use of, making value out of your experience. And if you can translate your experience into new vocabulary, right? If you can expand your domain knowledge and carry the vocabulary with you , then literally the language that you're using every day becomes more effective , it becomes higher leverage. You're going to have a better time in this new world . You're going to have a better time in your agentic coding efforts, in your collaboration with other engineers , with other uh functions, higher specificity , higher meaning dense, meaning rich uh words, right? This is going to help you uh communicate much better to other people, but it'll also help you communicate much better to an LLM. Now, uh, you may say, okay, well, you mentioned that Minecraft, both sides have to know what that is. Uh it is a for egone conclusion in this discussion that the LLM will know what you're talking about. Right? So I guess like an asterisk on this before we end the show. An asterisk here is this meaning density that we're talking about is kind of two-part . One, when you're creating context, it's kind of like creating culture where you and your friends have inside jokes, right? If you want to have inside jokes with an LLM, you need to teach the LLM the inside joke. It's not as fun , but it turns out uh that you can't just reference something that you know about that isn't common knowledge. In other words, knowledge that the LLM could have gone to find elsewhere. Right. So uh specific context to your organization, for example, is not going to translate right away. It's not going to translate right away unless you work in a domain where the uh the the domain that you're working in is both applicable directly to your company and specific to your company, but also right uh, extends beyond your company to other domain areas. Okay . So you have kind of a two-part or two-prong thing there. One is to use language when you're when you're trying to use this high specificity and high meaning uh rich language. It needs to be meaning that could reasonably, and now we're specifically talking about when you're prompting an LLM, it needs to be meaning that you are able to, you know, this is something that is common amongst you and others, right? Um and this is purely because we we assume that the LLM knows what is public on the internet. That's that's the basic assumption you can make. Is that the LLM knows about conversations uh that are had in forums, it knows about things that are on Reddit, it th it knows about uh you know, stack overflow, it knows about all of these things, books, these are things that are published, things that are accessible , you know, public or close to public, right? It's not going to know about private concepts or about inferred concepts from your own knowledge. But you can teach it those things by providing it in context, like in a uh, you know, for claw to be clawed.md or agents.md, or you know, whatever way you load context into your LLM, uh shout out to today's sponsor unblocked. Um and so if you're gonna have context loading in , then you can kind of build that additional uh you know context. aware So this is kind of the point of skills, right? The point of skills is to create meaning-rich commands to abstract a bunch of information that is not going to change very much to abstract that so that when you say a few key words, those those have really high meaning density to your skill set that you've built. Okay . So use this con cept. Try to learn an abstraction layer. Try to learn uh you know go go and um ask Claude about a code base. Ask Claude what you know what are the specific patterns that are implemented here ? Um you know tell me a tell me or it doesn't have to be Claude it's just um what I tend to use the most most llm's could do this. You could even do this with uh with the Quinn type model, right? You know what patterns are at play ? And you know, which which patterns am I not using that I might be tricked into thinking I'm using. What pattern am I using incorrectly? What try to learn about the surface area of something that you own and begin to build that contextual knowledge, that abstraction layer, the high meaning, high specificity vocabulary. Thanks so much for listening to today's episode of Developer T. Thank you again to today's sponsor, Unblocked. Uh head over and get your free three-week trial at getonblocks.com slash developer t. We've been talking about context and stuff a lot today and in this episode. Uh this is going to be a useful tool for you to build context almost immediately. Um the kind of context that a human would go and find, not just random MCP connections, but uh across all of your sources. Go and check it out. Head over to get onbox.com slash developer t. Thank you again for listening. If you want to give me feedback like the uh listener that we talked about today, uh you can join the developer t discord community that's developer t.com/slash discord. Uh this episode is available on YouTube if you haven't subscribed in the YouTube channel , go and subscribe. Leave us a review, leave us a comment, like, you know, like and subscribe. I guess this is the first time I'm saying it. Like and subscribe. Of course, share this with whoever you think is uh uh would would gain value out of it. This particular episode is doesn't have to necessarily be pointed at software engineers. This is useful uh a useful concept for anybody who is working and breathing living with AI these days um so uh and and beyond ai even um you know as we begin to kind of build this these abstract levels of knowledge uh so thank you so much for listening uh and of course, also we're in iTunes we're, in all of the uh you know the podcast outlets that you can imagine. Um so subscribe there as well. Thanks so much for listening. And until next time, enjoy your tea.