I got some feedback recently in the developer team discord community if you're not a part of that you can join it at developer t.com slash discord but we're not trying to do an ad I got some feedback asking me if I intentionally was trying to cause a flame war you know to have an overblown opinion, foregone conclusion that agentic 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, I'm going to give some specific advice to you. Because the same person asked, you know, what are some skills, that we can reasonably depend on, that we can build reliably. And we've talked a little bit about that since that episode. We've talked about some skill building that is more durable in the face of this revolution. But let's first talk about why am I talking about this stuff the way that I am? Why have I kind of just accepted this? And there's a couple of reasons. There's some very practical, simple reasons. 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 technology 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 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. We're going to take it to an extreme, 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. I'm just kind of picking a random date here, but June of 2023, we didn't have the same level of assistance that we would have. We could kind of treat AI, LLM-based generated tokens, et cetera. We could treat that as something that answers questions, essentially, right? But it's not, you know, we reject the idea of tool use. We reject the idea of context and spectrum 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 premise, the premise that we'd have to accept, if we imagine that we're going back to all of that, is that somehow we collectively, we have some experience, we have some kind of, 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, running these simulations. What does the future of this show look like if I 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, 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 not trying to sort of flame war 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 to the industry with new mental models, with a new perspective, with the right kind of information to succeed, right? And so whatever your people's misgivings are about AI, whatever their concerns are from from an ethical perspective, from a skill development perspective. I totally respect, 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, then we won't be practically useful, which is really the goal of the show. It's really my goal on the show is to be actually practically useful. You can take what we talk about and apply it as soon as possible, right? And we try to avoid getting into practical advice when it comes to actual implementation detail, right? In other words, I'm not going to tell you what design pattern to use on this show. I want to approach this from practically applicable models, mental models and skills, in the light of what's happening in the industry. tree, right? Okay. So with that in mind, with that kind of premise, I want 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, especially as you become more and more senior. And as you're using these tools, a kind of principle that you can carry with you that will continue to become more and more important as we take advantage of the power that LLMs are currently generating in the industry. But also this works outside the skill that we're going to talk about today. It works outside of the, this is not a specific skill that you're going to use just with your agent coding. is that we're not talking about the new, oh, there's something new that came out a couple weeks ago, the caveman coding or whatever it's called, where you try to save tokens by speaking in caveman-esque language. That's not the kind of skill we're gonna talk about. We're gonna talk about a skill that is transferable in a human environment as well. Part of the feedback I got is that just as I got on a roll, I jumped to an ad break and we're going to do that again and part of the reason for that is because we wouldn't be able to do this show if we didn't have sponsors so we're going to talk about today's sponsor this episode is sponsored by Get Unblocked. Getunblocked.com. The name of the company is Unblocked. Your coding agents have access to your code base and probably more. And maybe you've connected other tools. MCP, skills, whatever. Things that can call out and try to gain context. But it's not easy to keep up with all of those 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 documentation. 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? Agents tend to look in the wrong place. They don't really know what is, you know, highly reliable versus less reliable. They don't know who wrote what. and so you're going to 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. 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. so I want to teach you this skill or I guess point you to the 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 I want to talk about the principle today. This is inspired by a handful of stories that you've probably read yourself of people one-shotting. When I say one-shot, I mean in a single prompt. They provide a cloud code or something. they provide the single prompt and and then they get uh something that is close to app parity with a very complex uh piece of software right a good example is minecraft and so uh we look at that and there's something to learn from it all right there's something to learn from It's not that they chose 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. put. And so if you think about what the prompt was, the content of these prompts, again, we're not going to get into prompt hacking. That's not really 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. The principle is high context or high meaning abstraction. High meaning or, you know, this is meaning rich is another way to put it. Meaning rich abstraction. Okay, what does this mean? What does it mean to have meaning rich abstraction? action. If I told you that I want you to build Minecraft, if you have played Minecraft, then in one word, word Minecraft in this case, I've communicated perhaps two or three chapters worth of a 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 almost like a pointer that I'm choosing. It's a very rough, non-deterministic pointer because I don't know exactly how much you know about Minecraft. I know what Minecraft is, right? In this case, I know, let's say I'm asking for Minecraft. 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 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 total 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 reduced to make it useful. In this case, Minecraft has a specific kind of set of information. information. If I were instead to say, I'd say a block building game, then maybe your mind will pull up Minecraft. Certainly if you were, let's talk about LLMs for a second. If the LLM is using some kind of rag or vector space to determine whether that word is 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 similar conjurations. It would be something that triggers in your mind, probably close to Minecraft, but there's certainly things that Minecraft communicates that block building game does not communicate. All right. So by choosing the word Minecraft, I'm more specific, but still meaning rich. Think about it like a graph, right? And the bottom of the graph is specificity and on the y-axis, on the x-axis, then on the y-axis, you have meaning rich, right? 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 specific meaning rich and specific your ability to communicate in that area is going to give you drastically better results in your agentic coding I'll give you a very simple example that I thought of when coming up with the idea for this episode. And it's based on some of my own experiences in playing with the various patterns that were afforded by Cloud Code and other tools like it. uh 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 authorization 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 that didn't feel quite quite right. We don't necessarily need to hand something between the steps. Maybe we don't necessarily want it to be a single graph structure, right? Like a directed graph or like, 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 knew about another idea called a strategy. strategy. And in this case, 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, 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, you know, 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 multiple 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 don't want to explain all of that. It takes time. It takes effort. It kind of defeats the purpose. I might as well write it myself if I'm going to have to do all of that. But if I know, if I know the vocabulary, if I've learned about strategy patterns and when they're useful, what to do with that, then 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 this layer that sits above um 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 need to abstract it beyond patterns into, you know, a named thing, right? Something that 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, you know, is techniques, mathematical techniques. So for example, certain distance algorithms have a name and that name kind of implies the implementation detail. A good example of this is Monte Carlo. If you're not familiar with Monte Carlo forecasting, it's a basic frequentist kind of 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 what that language means, that's a high specificity, high, sorry, 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, continues to be useful. 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, for example, a conversation with another engineer, 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. 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 words 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 conceptual vocabulary when we gain experience. This is really the thrust of my argument here is that your goal in protecting your value, this is a huge concern amongst engineers, protecting your value as an engineer, a huge part of that comes down to simply making use of, making value out of your experience. And if you can translate your experience into new vocabulary, 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. world. You're going to have a better time in your agentic coding efforts, in your collaboration with other engineers, with other functions, higher specificity, higher meaning dense, meaning rich words, right? This is going to help you communicate much better to other people, but it'll also help you communicate much better to an LLM. Now you may say, okay, well, Well, you mentioned that Minecraft, both sides have to know what that is. It is a foregone 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 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. It's a 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 the domain that you're working in is both applicable directly to your company and specific to your company but also right extends beyond your company to other domain areas okay so you have kind of a two-part or two-pronged thing there one is to use language when you're when you're trying to use this high 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, uh, are able to, you know, this is something that is, 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 the basic assumption you can make is that the LLM knows about conversations that are had in forums. It knows about things that are on Reddit. It knows about stack overflow. It knows about all of these things. Books. These are things that are published, things that are accessible, public or close to public. 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, you know, for cloud to be cloud.md or agents.md or whatever way you load context into your LLM. Shout out to today's sponsor, Unblocked. And so if you're going to have context loading in, then you can kind of build that additional, you know, context aware. So this is kind of the point of skills, right? The point of skills is to create meaning rich 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 have really high meaning density to your skill set that you've built. Okay? So use this concept. Try to learn an abstraction layer. Try to learn, you know, go and ask Claude about a code base. Ask Claude, what are the specific patterns that are implemented here? Tell me, or it doesn't have to be Claude, it's just what I tend to use the most. Most LLMs could do this. You could even do this with a Quinn type model, right? What patterns are at play? And which patterns am I not using that I may be tricked into thinking I'm using? What pattern am I using incorrectly? 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 Tea. Thank you again to today's sponsor, Unblocked. Head over and get your free three-week trial at getunblocked.com slash developertea. We've been talking about context and stuff a lot today and in this episode. This is going to be a useful tool for you to build context almost immediately. The kind of context that a human would go and find, not just random MCP connections, but across all of your sources. Go and check it out. Head over to getunboxed.com slash developer T. Thank you again for listening. If you want to give me feedback like the listener that we talked about today, you can join the developer T discord community. It's developer T.com slash discord. cord. 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 and subscribe. I guess this is the first time I'm saying it. Like and subscribe. Of course, share this with whoever you think would gain value out of it. This particular episode doesn't have to necessarily be pointed at software engineers. This is a useful concept for anybody who is working and breathing and living with AI these days. So, and beyond AI even, you know, as we begin to kind of build this, these abstract levels of knowledge. So thank you so much for listening. And of course, also we're in iTunes, we're in all of the, you know, the podcast outlets that you can imagine. So subscribe there as well. Thanks so much for listening. Until next time, enjoy your tea.