Name: Designing IaC Interfaces That Work for Humans, AI Agents, and Whatever Comes Next
Uploaded: 2026-07-14T17:11:06.336Z
Duration: 49 min 8 s
Description: Designing IaC Interfaces That Work for Humans, AI Agents, and Whatever Comes Next

Transcript for "Designing IaC Interfaces That Work for Humans, AI Agents, and Whatever Comes Next": Hi, everybody. Welcome to today's ISEconf event, which is a spotlight, a single session spotlight, which we have not done yet. So really excited to, welcome to the stage when in a couple slides, Ginger, who's gonna be giving us a presentation on designing ISE interfaces. My name is Gareth Percy. I'm one of the organizers here at ISEconf. Glad to see everyone dropping hellos. Say where you're, dialing in from. Hello from Argentina. I'm an England supporter. So, oh, Damien, that might be rough, but welcome from Argentina. Real quick because I know there are some people here that are new to IEC conf. What is IEC conf? It is simply a community focused on all things infrastructure as code. It was started by SpaceLift back in May 2025. We've since done six events, both virtual and in person. We've done some at KubeCon North America. In Amsterdam, just this past March, we ran an in person event. We're gonna do an in person event in Salt Lake City if any of you are going to KubeCon North America. And, really, all the content here is geared by the community. It's presented by the community, the topics that you guys put forward that you wanna hear about, that you wanna learn about, stories, use cases, new tech, whatever that might be. And, again, all the speakers are sourced from call for presenters and you all then community. So, that's the community. There's there's links to the YouTube channel in the docs. We've got a LinkedIn page. It's a growing community, and, again, we're really happy with just the overall response and engagement that we have on these events. So that's the intro. I'd like to welcome to the stage Ginger Belani. She is a senior DevOps engineer at Mountain, and she is going to be presenting today's session. And that session is designing I c IAC interfaces and how that works with humans, AI agents, and whatever comes next. And with that, I will pass the stage to Ginger. Awesome. Thank you so much, Gareth. I appreciate it. Hi. My name is Ginger. Like Gareth mentioned, I'm a senior DevOps engineer at Mountain, and I'm going to be presenting a discussion about the power of good interface design and how the best interfaces can enable your engineering organization, whether your interface consumers are humans or AI agents or whatever else gets thrown our way as things continue to change so quickly, basically month to month. My excitement for designing consumable interfaces came from working with developers who needed to own their infrastructure, but who did not fully understand their infrastructure. And this is like a classic shift left culture side effect. I have infrastructure or non infrastructure engineers asking me basic things over and over again about how to use my team's Terraform modules. And this was before I could have Claude respond to my Slack messages for me. So I actually had to read, process, and answer these simple questions. I began really thinking about how we were presenting these modules. I began thinking about the interfaces, and I began thinking about my role as a producer of these interfaces. I think it can be useful to start by defining what I mean by an interface because it can be so general. In platform engineering, in order to shift responsibility left, we have to absorb complexity. We take complex things, package them nicely into something we could call a module, and abstract away details that don't directly matter to our users. The interface is what we provide to our users as an interaction point. A well designed interface is a way to turn a complex interaction into a simple interaction while getting all the same benefit of the underlying abstraction. So maybe for infrastructure or IAC domain experts, we could have a series of very flexible but complicated interfaces and modules, and that would work for an infra team, but it doesn't scale. If we want to enable engineering, we have to understand the best way to package complexity in a way that's consumable to our consumers. Maybe we need to make some design decisions and some trade offs in order to ensure that we can hand our modules to the rest of the organization and feel good in that shift. Because the definition of an interface and really even a module can be so broad, To ground us in reality, we will be talking about Terraform modules specifically. And honestly, even this leaves a lot of openings for what we can be considered an interface. Our interface is not only module invocation. It's not only variables as inputs. It's full variable structure, including description. It's the validation error messages. It's the registry that holds the module. It's the module metadata, and any associated documentation. It's the outputs that are used by downstream modules. And we could even take it further by considering the plan and apply context. Since I was only given about thirty minutes for this talk and not five hundred hours, we will only be discussing the components I have here. And sometimes, we balance the conversation between interface and module design since they inherently give and take from each other. So what exactly would be the point of considering all these different interaction points? Why should we spend time thinking about this? Because all these things accumulate into tools for us. We can enforce how infrastructure is built and make sure that decisions are carried out faithfully as we continue to shift left. We build out how consumers understand their infrastructure, and we include guarantees at multiple levels that our users are doing what we want and what we expect. And in fact, better interface design leads to better operational execution, both in humans and in LLM models. You can take an old model and make it perform better by giving it better interfaces. So how do we do this? How do we make good interface design decisions? We become more intentional about what the interface is saying and what it exposes, what it implies for the backing module implementation, and how it influences our consumers. So I see is code, which means we can pull lessons that may seem only relevant under the lens of traditional software engineering, but they're completely relevant to us. So let's listen to these lessons as they're given. In my journey to make things better for my consumers, I read a book called A Philosophy of Software Design by Jon Osterhout. Jon Osterhout is a computer science professor at Stanford, and this book is more centered around module design, but, again, the module and the interface are tightly coupled. The lemmas he presents in this book were derived after observing his computer science students and how they were constructing their homework programs, and he would kinda use these assignments as opportunities to study how the students thought about things in the failure modes he saw over and over. And our consumers are technical professionals, you know, they're not CS students, and we don't exist in a classroom setting where we can give grades to our consumers. However, these design principles are pretty solid, and they can be very easily extrapolated into our world. So using lemmas from this book, as well as findings from empirical studies, we are going to define strategies to designing effective interfaces. So let's start. First of all, as interface producers, we are kind of like authors, and like any good author, it is key to understand our audience. As I mentioned earlier, we're honing in on consumers that we encounter as we shift left. So we focus primarily on non infrastructure focused human engineers, application product engineers, full stack, maybe data engineers, but people whose jobs generally do not revolve around understanding infrastructure. And we are considering, AI agents or AI assisted humans as our secondary consumer. So we have human engineers, and we have LLMs or AI agents. The human non infrastructure engineer, primarily works on an application level. So they are experts in the domain that their services operate in. They are technical, but they may not understand the infrastructure domain. There's going to be a variety of understanding across companies that you'll work at. Your developers might hate Terraform. And as authors, we have to care a lot about and optimize for our audience's cognitive capacity as we begin to tell them stories and tell them to do things. AI agents, on the other hand, sometimes I refer to them just as robots within this discussion. They're technical in the sense that they are trained on technical materials, but they are not fully reasoning or rational, so they are not experts. Throughout proper IDAC Conf, we saw the many failure modes that are available to this audience in particular. And it's possible or even likely depending on your company that these agents are going to have a broader infra context than your non infra humans. As authors, we have to care for and optimize, for what I generally call computational efficiency. We could apply that to something like token usage, the cost in using these models in dollars, or the actual necessary running compute to run the models. Basically, the point is that even for this audience, there is a cost, but it's not exactly like human cognitive load, and we'll see why throughout the course of this discussion. By the way, throughout this presentation, I use these icons in the slides to distinguish whether or not a slide content is most relevant to a human engineer or an AI agent or to both. So starting with the first pillar, naming. Naming is, sometimes jokingly or maybe seriously referred to as, like, the hardest problem in software development, and that's for good reason. John Osterhout has a chapter dedicated to naming, quoting here, when choosing a name, the goal is to create an image in the mind of the reader. This requires us to understand who our reader is, really leaning into this whole, like, author audience paradigm. There is a lot of wisdom surrounding naming because people thought about it a lot, but I'm going to highlight those that I found directly relevant. These two points here. Adopt the shared organizational language and use vocabulary that's already available to the consumer. The idea is to meet your consumer where they are so that they don't have the burden of trying to understand the concept you're trying to teach them as well as the burden of trying to understand even the language you're speaking. So be intentional about what you expose or extract so the conceptual understanding isn't exhausting and that the linguistic understanding also isn't exhausting. Here, I have a quote from a study on API usability for humans that boils down to basically this. Sometimes the imagery of the name is more important than the exact technical accuracy of the name. This part of the study was comparing the usability of the name database versus repository, where repository was more technically correct because the API included functionality that surrounded the database but was not strictly database related. However, in the mind of the consumer, database means an abstracted object. Your consumers might not know or they might not care that an RDS instance isn't exactly a singular database, and it might not functionally matter. So let's talk about the story that I have. In one of my companies, we built an s three module, standard, classic, had some defaults and had some tuning options, one of those tuning options being life cycle rules. But as I was talking to my human engineers, they started saying something kind of weird to me, and they started referring to life cycle rules as TTLs, an acronym for time to live. And it wasn't a term that I was used to being associated with s three buckets, like maybe network packets or something. But in the application domain that my developers existed in, they knew of this idea of TTLs, and it was a name that painted an image in the mind of my users. So, no, that's not the technically correct name, but it was the name that would be given to my consumers for them to understand, and my module could handle the translation to life cycle rules in the implementation. Another naming assertion that is beneficial to both our audiences is this idea of unambiguous naming. Quoted from an anthropic engineering paper on writing effective tools for agents, parameters should be unambiguously named. In the example given here, basically say user underscore ID instead of just user to indicate the type of parameter that will be given as opposed to a full user object. Now this goes against some common software engineering wisdom that I've seen where you basically shouldn't include types and names in this way. However, that is more relevant to something like, name underscore int 32 or something. So you wanna be able to give structure without trapping yourself in the structure and having a prepended or or something at the end that gives the type is helpful without having to give this extra context, without having to look into the actual variable itself. Quoting the same anthropic source as our displayed quote for name spacing, we have found selecting between prefix and suffix based namespacing to have nontrivial effects on our tool usage evaluations. So it's easier for robots and for humans to understand the context in which something should be applied when it is properly namespaced. Stock the documentation. Quoted from a study on API usability for humans, in their research, all major usability flaws trace back to poor docs. But the thing about humans is that they get overwhelmed when they're inundated with too much or when they're given too many low level details, and they don't know what's relevant to them. So we have to keep it quick, to the point, abstracted, even in the documentation itself to make sure it's consumable. One easy way of doing this is to lean heavily on examples. You should be giving examples that show a singular pattern of concerns, but not just say a singular module invocation. So not just one call, but a series of calls that indicate one specific pattern. This should be the typical pattern, the common one that is seen throughout your organization most often. You can also give, developers live prod examples. So you can say, here's another development team that has done this correctly, and you can use other non infra teams as knowledge sharing multipliers. With robots, depending on the maturity of your context engineering, there's less that can be implied implicitly, well, at least implicitly and correctly by the robots. So giving them more context can reduce hallucinations as opposed to their human counterparts who will sooner abandon reading the doc altogether. And at least with the robots, you could run validation that they actually ran like an open file command versus a human. But something like contract details need to be made more clear in order for the tools to be used effectively. I'm going to show an example of embedding contract details into our interfaces as part of this discussion to help ground this in reality a little bit more. I have two quotes here, that are both from a study on AI agent efficiency when choosing tools. To summarize these tools, basically or to summarize these quotes, tool descriptions are lacking for what agents need, and better tool descriptions lead to better usage by these agents. So in summary, we should care about descriptions. The way that we are going to attempt to make good descriptions for our human users, but primarily for our AI agents, is to lean on a six component framework, created by a study that ran through how these agents were picking MCP tools. We'll talk about each of these in an example that we're going to bring up later. But something that I wanna point out is that throughout the combination of these components, they try to place different things together to figure out the ways that the agents are, most effectively picking the correct tools. And interestingly, they found that within descriptions themselves, having a shoehorned example in that description is actually the least effective. And this is going to be important for us in an example that I will bring up later. John Osterhout has a chapter in his book called Better Together or Apart, and this is a problem that I think about constantly. It's basically the problem of, should I bring these things together? Should I bring modules together, or should I tear them apart? He gives a highlighted answer here. Bring modules together if information is shared, if it will simplify the interface, or if it eliminates duplication. And separate the modules if it separates something that's general purpose from something that's specialized. And I'm going to present an example that hits on an additional point, separate or bring together in order to enforce a desired behavior. This section is a module discussion, but remember, module implementation is deeply blended with interface design. Our example starts with a consumer who wants an RDS instance that will host a database. Now there would be a lot of inputs here, but for the sake of simplicity, we're just gonna start with a name. And notice how I've prepended namespaced our module so that we know that this is a Terraform module in case it sits in a repository with other artifacts that are not Terraform modules. For our RDS instance, maybe we want a monitoring module. We know that the instance is not operating nominally. Here, the consumer is the entity that must know about this monitoring module and must tie the modules together. There's a clear immediate problem. How would my consumer even know to invoke a monitoring module? Maybe there's docs, or they copy and pasted a good example, or maybe we assumed or inferred. Maybe they saw this module as part of the registry. Maybe there's a rule somewhere in our system that says these modules must must be placed together or whatever it is. But the obvious solution and the one that follows Osterhaus guidance, because it brings things together, it simplifies the interface and it eliminates duplication, is just to have the RDS module absorb the functionality of the monitoring module. To add to this example, what if we wanted our RDS instances to be encrypted with a customer managed KMS key? We could enforce this through aggregation in the same way that the monitoring module is encapsulated within the RDS module proper. And even though this would seemingly fit in line with our design pattern, there's actually another layer that we have to consider. If we bundle our key module, it lives in the same life cycle as the RDS module. Meaning, if we delete the RDS instance, we delete the key that would let us back up the RDS instance from encrypted snapshots. And maybe this is operationally sound in some environments, but depending on your industry regulations, data requirements, whatever, this could be pretty important. And even if this example isn't your exact circumstance, the lesson is the same. The lemmas and the evidence we discuss here are not strict rules to abide by. It's guidance for you. It's observation, and it works under the handling of your expertise. It does not supersede your expertise. So an alternative and valid design would be to separate the KMS module so that your consumers call it alongside your RDS module. We're gonna talk about mental load, which is a generic term that I'm using here to mean cognitive or computational effort either on the side of the humans or the robots, since we're going to talk about two concepts that impact both our audiences. I put these concepts under the umbrella of mental load because these are things that will put extra strain on our consumers as they attempt to construct their modules. John Osterhart again. Reduce the number of places where exceptions have to be handled by consumers. One way to do this would be, of course, to add some validations. Consumers wouldn't have to be worried about blowing up resources because they tried to divide by zero, for example, but they have to take on the responsibility of consuming and acting on a validation error message in this case. And the more structural way to enhance the error handling experience is to actually define those errors out of existence. On my first read of this book, I had no idea what this meant. And, actually, instead of explaining it now, I'm gonna put a pin in this, and we're gonna come back to this later. We're gonna talk about the second concept under mental load, and it's how much they have to bear the weight of decisions, of making decisions. From Alsair Hout's book, chapter eight, Pull Complexity Downwards, configuration parameters are an example of moving complexity up instead of down. Now for us, config parameters through variables are actually pretty integral, but the spirit of the quote stands. Can you, for example, compute something through a local variable instead of making consumers pass in multiple variables? And validations, like we mentioned earlier, are an example of pulling complexity into the module as well. And, essentially, those two things allow consumers to tune configuration as opposed to make decisions. You know, module producers, us, we're the people that make decisions, and consumers combine our prepackaged decisions as a means to an end to get their service operational. So let's talk about tuning configuration. At this point, as a consumer, after everything we have learned in this discussion, I have read some form of documentation. I understand the shape of my architecture as much as I need to in order to get my service up. I can read the names, and I can read the descriptions of modules, variables, and I understand all of this function, behavior, the nature of things. I have a sense of what pieces I will need and how to put these pieces together because my module producer considered aggregation and separation. I've built a mental model, and I've built the module relational model. And now I actually have to go in and tune the engine to meet my needs. So let's take a look at a super simple example where we have some kind of compute provisioning module, and we wanna offer our consumers a way to customize this configuration. And I'm purposely keeping things pretty intentional and pretty generic. So we're gonna start with a straightforward bull flag, whether or not we wanna have our service running on auto scaling compute or a fixed number of nodes. We have set a min size and a max size, presumably for when we have auto scaling enabled, and we have an instance count, presumably for when we don't have auto scaling enabled. In this design, in order to enable Auto Scaling, you actually don't just set the flag. You have to set the flag and then configure another thing, at least this minimum size variable. So your consumers might set auto scaling, think they're totally good, and then get an error about not setting an auto scaling range. And they'll come to you and say, but I did set auto scaling, and you will get pinged about it. You should have variable descriptions and validations to help support the purpose of these variables and ideally cross variable validations unless you're on an older version of Terraform. But those things are supplementary to solving what is more of a structural problem. The the issue is this current design follows a mental model that's more in line with, like, a GUI drop down. We have conditional options based on this enablement toggle, but we don't have a GUI here. We have four separate but related levers. So what should we do? How can we improve this design? We can do the things that we have been doing, the tools that we've given so far. We can try to use same consistent naming conventions. We can include documentation or variable descriptions. We can pull complexity downwards by including some validations as well. But we're not considering the mental model of our nonexpert consumers. In our example, our consumers are asking us a simple question, where do I go to update my services scaling config? And we give them this convoluted answer involving a dance of four variables and traps along the way, when instead we should send them to one spot, a safe space. So even though we should definitely include all of these elements in our design, the core of our problem is that these errors are possible at all. We need to structure our interface or module implementation to make error states unrepresentable, and this is what it means to define an error out of existence in practical terms. First, we take our four levers and we combine them into a single configuration panel, a variable that I just call scaling here. We answer our consumers directly. Where do I go? You go here. We include a description that hits on the most important components of our six component framework. I describe the purpose of this variable, the guidelines, when and how to use it, limitations such as mutual exclusivity between our two configuration parameters, parameter explanation. I keep it short but complete, and I have excluded any examples here for the sake of brevity. And then we structure the type in a way where it removes the need to have some of our previous validation. For the sake of brevity, again, I've excluded the actual code for default values in some of our variable checks. But for example, we don't have to check the failure path where auto scaling is set, but a min max value is not set or vice versa. Using Ouster Hout's strategy, we define this error path as unrepresentable due to the type structure because now they are coupled together. This doesn't remove, for example, the need for us to do a validation that the minimum is less than the maximum, and it also doesn't remove the validation or the need for the validation to make sure that we have set these two parameters under a mutual exclusivity. But with this variable versus our previous spread, we give consumers a straightforward answer to the question, and we provide them with a structure that guides them to making the correct tuning choices from the absolute beginning. That's defining an AR out of existence. So what comes next? The story so far has looked like this. As infrastructure engineers, we first created modules and interfaces for ourselves and for our peers. Design here still matters, but there's wiggle room. We can use different jargon. We can make different assumptions versus when we began shifting left. And now our modules needed to be consumed by other engineers, non infrastructure engineers, as they began going through more DevOps culture transformations and owning their stack more and more. Now we live in a world where both human engineers and AI assisted engineers need to be able to seamlessly utilize your interfaces, and you may have autonomous systems that are more loop based, less continually human triggered, and our modules need to serve them as well. And depending on the maturity of your autonomous ecosystem, you could have multiple layers of agent orchestration, including sub agents that are controlled by agents. And eventually, if the ecosystem grows to be so well defined, so well validated and tested, and so abstracted, we could end up in a place where modules and interfaces are fully designed by agents or agents, and our role as Interface Producers shift up an abstraction layer. Even here, you matter as an Interface Producer because the foundation you lay for your agents will determine their usage and your troubleshooting experience down the line. This all centers around an idea. We need to design our modules and interfaces to work for multiple audiences. These audiences may look different from each other, and they may change very quickly over a short period of time. So what happens when our audience grows again, changes again, evolves again into something brand new? We do the same thing. As with every other major shift, we follow this path. We understand and we empathize with our consumers. What do they know? What don't they know? What languages do they speak? What have I observed about them? We decide what we're optimizing for based off of what we know about our consumers. We use a shared language, we meet them where they are, and we do not add toil or mental load. We create reasonable boundaries and abstractions that guarantee both safety and lack of cognitive load, both design wise and also domain wise as far as operational excellence. And then we build things in a way where your end users end up doing what you need them to do. So in closing, we've talked a lot about lemmas and assertions, evidence, opinions, art and design and science, and we've mined a lot of tools throughout this discussion. But the key point is actually this. The best design is the one that works the best for your organization. You have to decide what matters to you, to your company, your operations, and to your consumers. And really, it all starts with the idea that you need empathy for the people or the systems that use the things that you build. Thank you so much. This has been my time. This has been my discussion. I hope that you were able to get something out of that or at the very least that you enjoyed my That was great. Thank you, Ginger. rambling. Thanks everybody for the activity in the chat. We did get some questions in the q and a, so we can go over to that. If you go to that tab, you can see there are some in there. If you wanna upload the one that's interesting to you, you can also ask some more questions. But, yeah, Ginger, if you're good with it, we can jump over to q and a. Yeah. Okay. Cool. So let me pull it up, and I can, share this on the screen. Let's do alright. So will organizations even use Terraform or Ansible anymore given they can make direct API calls using AI agents? Yeah. I mean, it's going to be a business decision at some point. It's going to be an engineering decision, but the the benefits of having this extra layer are less about capability. Right? Right now, agents could run API calls like you're saying, and we could attempt to build in, evals and validation processes there, or we could use Terraform as the deliverable. So you may feel more comfortable giving your agents more autonomy in performing actual mutation actions if those mutation actions end up delivering a module implementation, a set of static files that can go through validation processes that are tried and true. Terraform has been around for quite a while. So I would say, yes, we should still have some form of layer in between our agents and the things that our agents are actually mutating, both for state, audibility, sanity check reasons, additional verifications that we can do on those artifacts versus direct API calls. It could be the case. Maybe it's not IAC. Maybe it's something else. But this intermediate layer to me does seem pretty necessary unless you are an extremely mature organization in that way. Yeah. I just shared the link to a playlist from the IC Conf back in May, and this was a common theme that came up in sessions and and, discussions. There's a couple sessions in that playlist, which, you know, kind of center all around this. So if you're interested in this, definitely go check that out. Alright. So thank you, Ginger, for that one. Let's go with this. So if we have hundreds of human end users, how would you suggest getting that baseline of common understanding for vocabulary, maybe using surveys? Yeah. What were your thoughts here, Ginger? Yeah. This is a great question. It is a little bit outside of, interface design. That's why I didn't include it in this discussion. It's a little bit more pertaining to developer experience. And the best way to do it, I would say, it depends first on the shape of your organization. If you very similar to how we would solve any big problem. Right? Break it down into smaller problems. Maybe there are teams that actually do not share the same language. And if you use TTL in one team, that does mean something different than TTL in another team. So a big survey in that case wouldn't actually help you. Right? Because now you'd have to include some form of metadata in that survey, like, what team are you on? How do you think about things differently. So at the very beginning, I would say it's up to you to understand the organization as a whole. That's going to be the thing that guides your next decision. You could do something like surveys, but surveys have kind of this natural bias selection. You're only gonna get the people that feel very strongly one way or another, and you're not going to necessarily get the average case. You could attempt to look through their actual application code. What phrasing do they use often? If they say the word interface, what does that mean for them versus what we mean by interface? You can attempt to read their documentation. This might be a little bit wild, but I have worked in companies where we just show up sometimes to stand ups and we listen to our development teams. We hear about the things that they are handling, and we almost implicitly begin adopting their language as we talk to them. So this is maybe a hand wavy answer to this, but I would say active engagement within your organization is the core of anything else. Any other, you know, specific implementation guidance I could give all ties back to, like, you need to understand, you need to understand the organization and how your developers operate within the ecosystem and the platform that you own. Yeah. Great point. Great point. Someone did I saw a few comments and questions in this. Yes. This is being recorded and will be shared afterwards, both as a video and and if Ginger's okay with it as well, we can share the the PDF as well. So, yeah, this will be shared. So what, what tool do you use to review I see in CICD? There's a lot of tools. I think something that is sort of implicit as part of this discussion, but I don't state explicitly, is the tools that you have are still valid. You can be, you know, AI enabled engineer and still have basic things that say in in your pipeline, like, check the number of resources destroyed and make sure that it's never anything besides zero. These things can exist together. So it's less to me about the tool and more about the abstraction layer that the tool hits on, you could include something like codex in your pipelines. Right? And it would do a lot of, like, higher level inference. It would look at plans and maybe it would try to correlate things that it, knows from other data sources. And I think you should have that, but you should, at the same time, have that very basic check that I just talked about. You know that resources should never be destroyed. Type in in GitHub actions or or, you know, a policy wherever you're running your Terraform plans that if if something is greater than zero, for example, all of these static code, these if statements, these are all still available to us. But I would I would try to hit on multiple levels as opposed to being obsessed with tooling, if that makes sense, because the tooling can always be genericized. It's going to be policy enforcement. It's going to be mutation checking. It's going to be intent checking. So less about which one you pick and more about are you covering that entire spread. Alright. Great answer. So here's the next question. So how do you feel about a Terraform module sandbox that allows developers to develop their own custom module purely through prompts? Terraform module sandbox that allows developers to develop their own modules. I would say I would consider the what I want out of that, I guess. So, if my goal is very quick iteration, if my goal is, you will always have ephemeral infrastructure ready for you to just hammer and blow up and you don't have to worry about impacting a prod environment, this does not necessarily get us closer to that world because instead of using modules that will exist in higher level environments, it sounds like in your sandbox, you build something just for you. Is that thing just for you going to be available in dev and QA and prod, or is it only for your sandbox? And if it's only for your sandbox, then what is the purpose of your sandbox? It is just to play around and maybe learn a little bit about infrastructure so that you can make better modules in the future, maybe. Maybe that's a good training, opportunity. But if you're just saying, I have a sandbox, and I want to build things in the sandbox, and they live and die in that sandbox, and they're never used for anything else, I wouldn't spend my time building that for a developer. And instead, I would spend my time really focusing on their local development environment and the ways that I can tie in sandbox resources that already exist as opposed to ways that I can help them build their own modules within their sandbox, if that makes sense. Yep. And Brian says, you know, got us building TF modules. There's five coding Terraform. So I think your point is a good one of, you know, to to what end? Alright. So Dhruv here asks, it's a bit of a longer one. Are there any quantitative metrics you would use to measure whether your design interface is working well or not so you can improve and iterate? Or is there a way to go more qualitative, like end users bringing up issues, agentic workflows not creating desirable outputs, etcetera? So, yeah, how do you kinda get that feedback loop of whether your interface is working well? Yeah. Good question. I do hit on a lot of the qualitative things because it almost stems from, my quality of life as I as I do platform engineering and whether or not my time is sort of saved and and respected in that way. This my answer to this is going to be similar to my answer about the sandbox implementation. When we talk about good interface design, the goal is not that we have a set of metrics that prove we have good interface design in isolation. Right? So we're not going to go to our engineering leadership and say, I followed the six component framework of descriptions for all my variables, and so that's my quantitative check. Like, we we did it. It must be something that supports an overall goal. So instead of saying, let's create a new system of measurement to make sure that our interfaces are designed well, I would say, use all of your same systems of measurement of operational excellence as a whole. So something like, saving a DevOps engineer's time and mental bandwidth, that should have already been a metric that you use to determine operational excellence or engineering maturity. Shift left, are you doing DevOps culture correctly? That's already part of it. Something like the number of failed plans or the number of production incidents, these things should also be getting better as a metric through interface design. So it's less about, you know, I did interface design and now I can see, you know, my interface design numbers going up. It should be, I did better design in these ways and I can see my overall health of my organization continuing to increase. Alright. Great. So Cody asks, how else have you learned about writing bespoke IC modules and the tips, tricks around designing these interfaces? How else? So, yeah, the the ones that I think I hit on primarily as part of this discussion, is this the book. Right? The book is not so much centered in evidence as much as ethos. Right? Somebody who has been in the computer science sphere, in in the technology sphere for a long time and has thought about things. And so this kind of veers more into design and art because it's very heavily opinionated. And then also empirical evidence. So for all of the times that we might have an intuitive sense about how something should be, we check ourselves. We go see, is my intuition wrong? Is it biased? Is there a real measurement that, again, can help ground me in reality? Besides those things, this alludes back to one of my earlier answers, which is, like, just engagement. You are also a channel in which to learn lessons. Right? So you read books and you read empirical studies, and then you go talk to people, you engage in your organization, and you find out the secret hidden failure modes that people aren't talking about because sometimes they don't even know that they live in a flawed world. They go, this is my workflow, and this is how I do things, this is how my team understands things. And oftentimes, those pieces of wisdom truly can only come from mining these personal connections over time. Your organization probably will not have an empirical study about how your developers use your Terraform modules. You can attempt to do some level of that, but it starts like like I was saying earlier, it starts with you, and it starts with you stepping out of your zone, stepping into the world of the people that you are building for. It's platform engineering, it's also a product mindset. Right? We produce things for consumers to use. So it should be up to us. It will be very specific to us and the the moment that we live in and the company that we are in at the time. So talk to people, I guess, is my is my third secret, channel that you can use. You do a whole talk just on that subject. Talk. to people. Developer experience. Yeah. Yeah. I'll do we're running up on time here. So I'll do, one more, which I think is, you know, kinda is the same thread here, around you know, Lucas asked about it's a tough idea to swallow the the renaming of some of those variables when you're talking about the life cycle rules versus labeling it TTLS and, you know, educating users on, again, those existing labels you might have versus adopting labels that are more in line with how they understand the vocabulary. So, and maybe just a response here to, to Lucas's question. Yeah. Absolutely. This, in my opinion, is where the art and design come in. And when we talk about platform engineering and shifting left and pulling complexity in, what a lot of that means to us is that we have to put in more effort than the people using our stuff, and we have to decide when it matters in insofar as when we compromise versus when we don't. For this specific example, the reason why I compromise is because the terminology doesn't really matter. They actually already understood this idea of an object will expire under specific criteria. I don't need to teach them anything there. They they understand that conceptually. And so the only shift that I would have to do is make sure that I use language that evokes that same concept. I will give an example of something where you should, spend time educating your users. This is just kind of, you know, off the top of my head, but if you are allowing users to make an application load balancer versus a network load balancer, for example, that distinguishment is important and it is something that may not have a one to one mapping into a terminology that developers are used to. So just changing the word may not be the conceptual switch flip that they need. They do need to know the difference in which the load balancers, you know, that they're operating at a different OSI model, for example, or a different layer on the OSI model. And that is a case where I would say this is important to know because the core concept changes based off the language. Versus life cycle rules, the concept stays the same regardless of the terminology that I use. So to reduce cognitive load while still making sure you understand the behavior that you are, opting into, that's when I would shift my language. I I hope that answers that question. Alright. Great. Well, like I said, we're just a little bit over time here, so thank you everyone who joined today. Big thank you to Ginger for the presentation. Super interesting. We will be doing more of these single session, ISEEC confs. I just launched a survey just to get some feedback, quick rating. And, again, all the topics that we source here are based on input from you all. So if you have ideas of content types you wanna hear, formats, certain topics, please let us know. I'll also drop in, Ginger's LinkedIn profile in the chat if you all would like to connect with her. Thanks again to everyone who joined. Ginger, thank you, and we will see you on the next ICConf event. Thanks so much.