Coming from a software engineering background, but mostly spending time teaching non-technical domain experts how to code has been an interesting challenge because my first impulse or inclination is to teach and explain through software engineering principles. But in practice, if you’re not a software engineer, most of the time you don’t actually care about the specifics of the software, at least not initially. I find that first I have to sort of play out, then catch my impulse to explain through the software found, you know, through the foundations of software engineering and with software engineering terminology. And then from there, back my way into what the actual goal and intent is. An example of this is a conversation that I had with somebody who had created a large complex web app for displaying data in lots of different types of ways and across many different facets. We’ve been discussing how to make the web app more maintainable and extendable as it grows in size, which whether you’re a human or an agent working on a code base, as the code base grows in size, more time is dedicated to research and maintenance of the code base and building of understanding as opposed to early on when there’s a lot of greenfield and fast development. As we were having these conversations, I was thinking about how I might introduce the concept of refactoring and how that plays into making the code base more maintainable, talking about design patterns and the shape and structure of the code. But after thinking about it for a while, what I realized in practice is refactoring and the structure of code bases in general are just the, I guess, commitment to various trade-offs, right? Certain things become easy when code is organized in certain ways and certain things are harder. There’s no perfect structure. There are only trade-offs given what you’re optimizing for. And with that understanding, I think I found a more sort of salient and practical argument or line of thinking to trace for somebody who is not familiar with software, which is that you need to think about what you are optimizing for, what things you want to be flexible versus what things you do not expect to change. You, of course, can’t optimize for everything, but you can think through the types of things you may want to do in the future and then instruct an agent to organize your code base, optimizing for ease of those types of changes. That grounds the instructions to the agent in the domain you’re working in based on the work that you expect to do, but doesn’t necessarily require deep engagement directly with the software. And so I think that this will be an interesting on-ramp to try.