Source note: This is a dry-run recording of an opening keynote for AI Native Dev Con Spring 2026. Single speaker throughout: Guy Podjarny (founder/CEO of Tessl). The transcript was produced by speech-to-text and contains artifacts — likely "Renault" → "narration", "stock" → "talk", "hardness" → "harness", "OpenClaw" → an open skill ecosystem, "Ant" → a coding agent name, "AI NATV dev con" → "AI Native Dev Con". Quote these verbatim when citing; you may parenthetically note a likely intended word but do not silently correct the source.

Pre-talk disclaimers (lines 1–18)

Hello, everyone. Thanks for being the guinea pigs for my note for dev con. I will start with a few disclaimers. I have not yet given this stock as I've been editing it. I've been building it in Claude design. There's a couple of visuals. It turns out it it really does not work with images of any kind. I am doing Renault. And and and so it's not you'll sort of find, you know, for instance, a a Venn diagram replacing our infinite loop for a context development life cycle. And I do not have my speaker notes over here after this little element over here. So there's some improv going on right now. All that aside, I I would love as we as I give this presentation on it. It is the the opening talk to a bunch of hundreds of people, it has clearly a fair bit of representation in it. I would love post the talk, any some feedback and and comment on it as as harsh as it needs to be. I will put a bit of a okay. Just mind the time. Yeah. And maybe one last one is I will to you as the audience of AI NATV dev con. So it is what it is. Cool.

Opening & three-part agenda (lines 19–44)

Hello, everyone. Welcome to AI native dev con spring twenty twenty six day I'm excited. The proper response. I'm excited for a couple of days of of learning, of sharing, I am Guy Podjarny. I'm the CEO and founder of Tessl, who powers the AI native dev con And, yeah, looking forward to the news. Two days.

So when we started Tessl a couple of years ago, we did it out of the belief or, you know, that software will transform from revolving around code and implementation to revolving around intent and instructions. And two years ago when we said that, we didn't really quite know what it would look like. But increasingly, I think we now see what does agentic development AI native development, might be? What is it that we might be developing?

And I think okay. So already lost one. Line over here. Okay. I think I will cover in this talk three things. One is what are the the kind of the new units of software in agentic What is it that we're starting to build and evolve as we seek to make agents better? Two is I will try to make the case that skills are the new code, and the primary thing that we will be editing as developers in this world. And then talk about the dev tools that we need to be able to develop such skills.

Unit 1 — Tools (lines 45–68)

So let's start with the agentic development units of software. So we're seeing more and more that what we build to make agents successful falls into these three buckets of tools, context, and harnesses. I'll dig into each of those.

Tools are the easiest to understand. Right? These are pieces of software that we call to be able to do something deterministically, and they really are what turns a model into an agent. Really, able to interact with the world and affect it, and is able to get information out. And there are many types of tools, but the dominant ones are CLIs that an agent might shell into with Bash, MCPs that it might call directly, and APIs that it might call over the network.

And each of those are means of performing an action in an efficient manner without taking up tokens. And it's oftentimes faster, cheaper, and better doing it. For instance, you know, with with the grep, you can find a bunch of information. Across your different files without reading all the content of those files. Saving a ton of tokens. Or f f m peg, do some video editing for you in a way that is much more reliable and again much cheaper and much faster than having the model try to modify the basement [basement → likely "bytestream"] itself.

So very, very powerful tools, and because tools compose agents can also create custom tools for them for a variety purposes. They can do it through code or they can pipe things together, and and create things that really are suitable tools that will save them and will give them all of those benefits of tools for a specific point in time.

Unit 2 — Context (lines 69–98)

The second unit is context. And context is really all about giving the information giving the agent information that it either cannot know, like opinions, or that it can find out but it is very inefficient or error prone to do so.

And in practice, when we look at what type of context we provide to agents, we mostly see kind of practices and policies. Right? We got together and we agreed that this will be our API design or this is our security policy. These are unknowable things for the agent unless you provided it with that context. Specs that are more about information about either the product you are building or a product that you are using. So the the specifications of how this product works. And then workflows, methodologies of this is how you will do incident response. Right? And this might be because trying to help the agent succeed, or it might be just because you want alignments. Like, I know you can do, you know, log parsing, but I want you to do it in this consistent way. Across the board. So these are the three primary buckets of context we provide.

And the other dimension we have for context is how do we how do we inform the agent about it And again, we're sort of seeing three primary things here. We're seeing rules, which we sort of always shove into the context. You will always have this in any LLM message that you send. We have skills that are loaded on demand by the user or with some hints. And then we have passive context as docs, information like architecture MD and such that might just sit in your repository and be available to the agents to find or when the user directs it to it. And again, there are probably many variations of those, but those are just common patterns.

And just like tools compose, skills compose as well. First of all, skills called tools in fact, many skills are created to tool tools and to wrap tools around with all sorts of workflows. And then skills can call skills. This is one example of the skill skill optimizer skill. Which is a workflow. So it it runs scenarios, and then it creates scenarios for a given skill. Runs the evaluation. It learns from the results. Each of those is its own skill. And in turn, it uses different tools. And so skills also compose which is great. What allows us to scale them and allows us to do things that are bigger and bigger and bigger. It's a core part of why software is powerful.

Unit 3 — Harnesses (lines 99–138)

And then the latest entrance to this world is this world of harness. And a harness, is the is again deterministic software that wraps the probabilistic model. For instance, Claude code is a hardness. It takes the LLM and it chooses where do I read the context out of, you know, through maybe a Claude MD, or some configuration file. It chooses which tools are available to it. And so it it harnesses the model. It runs around it. It provides a UX around it.

And it does so in one parts to help the model, to be successful and and give it, for instance, agent search for capabilities to to find information or otherwise understand what makes it tick. And sometimes to constrain the model, to actually limit its ability, running it in a container with limited permissions, or saying you will always do x y zed. And there are many types of harnesses, and we have our kind of clod coat with those sort of SVG made up icons over here. You know, we have Claude code and Cursor and Ant. We have the sort of the known agents out there. They're all harnesses. They all make slightly similar decisions, but they make them in their own unique way. They all have their choices of UX and constraints. So they harness the models different ways, sometimes the same model.

So harnesses, are, you can build your own harness, which is becoming easier and easier over time. But oftentimes, you don't build your own harness, but rather customize a harness to create your special sauce of it. And you do that typically through agent plugins. They might bundle in a bunch of tools and a bunch of skills. And through another part of those plugins which are hooks. And hooks are interesting. Because they are, again, deterministic software that would run at specific points in time. Right? Every time before you run a certain command, run this piece of software. Every time a prompt comes in, inspect it and maybe modify it, maybe block this prompt that comes in. Again, deterministic software that takes away decision power from the model.

And we're seeing it being used in very powerful ways in the real world. We're seeing Intercom, for instance, not rely on the model to load the skill with guidance about how to create pull requests, but rather set up a hook that says, you cannot run GHPR open unless you loaded that skill. We're seeing OpenAI's harness engineering block commits unless certain test coverage has been reached. And we're seeing in Tessl's world, we're seeing people use hooks to limit, and we're helping people use hooks to limit the skills that they load so that they're only coming from a trusted source of the Tessl So these are all examples of taking away probabilistic control putting that into your harness, into your deterministic harness.

And then the last thing I'd say about harnesses is that the harnesses also compose. And so you can have, for instance, a harness that is meant to take in some some input from a ticket and spit out a production notification, and it might combine product harness that really knows how to elaborate on that ticket, a coding harness, is optimized for implementing it, one that does the security analysis, one that does the DevOps deployments. All of those might be different harnesses. Optimized and usable in their own way, composing into it. And I I've been calling that a factory line. Just to disambiguate that from the harness that we use locally.

The agentic software stack (lines 139–158)

So as we look at these things, we're starting to see a software stack We're starting to see tools that sit at the bottom. We're seeing context that sits top of that and composes with the tools. We're seeing harnesses, top of those. Factory lines which clearly compose into factories, is not a finite list, and it I'm sure this is AI. Right? Like, this will change often. But it is still a picture now of what is it that we might be developing. These are all reusable units that we're building.

Why skills are the dominant reusable context (lines 159–172)

Within those, the the asset that developers deal with the most is context. Know, most of the time when you're developing with agents, you're telling the agent information about what you wanted to do or how you wanted to do it. And so those evolve things that are more interactive or project specific like prompts or documentation, into things that are more reusable and and maybe like library likes. Roles are a little bit in the middle, and then skills are the most sort of dominant reusable unit of context that we've built it.

And so this become like code. That you build, especially the reusable bits that that you distribute around and use again and again. So for simplicity, I'm gonna focus on reusable skills and I will call all context skills just to sort of spare myself some words as we build around.

I did not fill in the yet, but, skill usage is exploding as you clearly know. It's exploding in the public ecosystem, exploding in the inside organizations, And as a result of that, you know, we're getting more and more value. We're leveling up more and more with agents. But we're also seeing a bunch of challenges in if emerge, which gets me into part two the challenges around skills.

Problem 1 — Security & governance (lines 173–204)

So as people embrace skills more and more, there's and as skills behave more and more like code, we're starting to see problems that seem reminiscent of what we've seen when software growing. And those revolve around security and governance, collaboration and reuse. And life cycle, and continuous optimization. So let's talk about those.

The first concern as we start distributing reusable context is, sadly, security. At the end of the day, skills are something that the agent picks up and executes, right, and invokes. And that might be good or that might be bad. We're seeing a fair bit of skills, skills that are explicitly written to manipulate the agent to do something malicious. Especially in the OpenClaw world. We've seen over 30% of skills being malicious. We're seeing, what I call negligent skills, which are skills that lack safety instructions, every time you, you know, update like, go off and update the database with this new information. Do not delete tables when you're trying to do that. You know? Do not, open a public repository with the information when it asked you to check-in something to our repository and you do not have access. So these safety instructions are lacking, and as agents do reward seeking, they might, go out of bounds

And then we're seeing skills that are just vulnerable. They do things that probably the most common example here is API keys that are used in the open. So skills that might guide the user to say, hey, give me your API key, and I will set everything up. And then the user paste that API key in the public's in the in the agent's terminal. And that gets captured in the logs, is an insecure state.

And so security risks are there, and you have to control them. And they naturally lead into a concern around governance, which is to say, well, if someone did install a militia [militia → likely "malicious"] skill, would you even know? Right? So you wanna say, which skills do exist do exist in your org to begin with, some basics or supply chain hire, hygiene? Do you wanna know who is using which one and ones can be cleaned up so you know how to clean up the mess? And again, one of them did prove malicious, how would you even find out? Can you track what has happened? So just sort of annoying some software supply chain needs.

Problem 2 — Collaboration & reuse (lines 205–232)

The second problem that we see when we scale skills is is around collaboration. And I like this story from this developer a platform developer in a in a unicorn. Who was telling me the story of how, you know, everybody as skills came along, everybody started building their own skills, and that was wasteful because everybody was creating the same skill over and over again. So said, okay. We wanna create something shared. So they opened the Git repository, everybody can add to it in a very bottom up fashion. So everybody added skills to that repository.

And very quickly, it became a mess. It had a bunch of duplicates, and people were looking around as well. I don't know which one of these I need to use. They had a bunch of cases where someone built it for one agent, but it failed on another agent. And again, it wasn't clear that that will happen. And then it wasn't clear how would you how would you contribute or collaborate on a skill. So you had cases where someone has a skill, someone comes along and proposes a change, it's like, well, is that change in making it better or making it worse? So the end result of that was that nobody trusted anything that they took out of that PR, and everybody went back. To creating their own skill. And wasting that work.

And so collaboration is not easy in this world. And I would say that it really comes down to like, in that story which I hear over and over again, it comes down to these sort of two primary gaps. One is we lack quality testing. Right? We today in the skills are limited to works on my machine. Right? I tried it and it ran. And we do not have a means of sort of saying, well, how do I how do I know that my skill is quality, let alone convince you that my skill is of high quality, and how do I keep it of high quality over time? And then the second aspect is dependency management, and we'll talk about both safe more, which is kind of an appreciation that when removing skills around, are creating a dependency. On someone else. We now need to think about how do we how do we fulfill the contract. Around that dependency. We're not just copying some bits around. At the moment, skills are more like copying something down from Stack Overflow.

Problem 3 — Lifecycle & rot (lines 233–262)

And then the third problem is is really thinking beyond that initial creation into a life cycle. And the reality is that skills, as they get executed by agents, over time, will rot just like software rots. I think we all have had that experience of how software, if you don't maintain it, if you don't make it up to date, becomes useless and then eventually harmful.

And skills are the same. They live in a dynamic environment in which the software that they represent changes, in which the models that they run upon changes, the agent that executes them changes, even the practices that they are meant to represent changes. And so if you don't have a good way to maintain and update them over time, they will become not very effective, and eventually they will become harmful. And misleading.

The flip side of that in the life cycle that we have all this great exciting opportunity in the world of agents to make that maintenance and even the concept optimization automated. We can tap agent logs A lot of these slides need a lot of improvement. We can tap agent logs. And and pull requests and activity that we see to gather information in a much much easier fashion than what we've had in software. About what works and what doesn't work, what mistakes, how do people respond. And extract from that modifications to skills or even creation of new skills to come out.

And so we find ourselves with this sort of carrot and stick option. Right? If we just create the skill and put it out there, it will probably rot and it will become problematic on it. But if we do improve invest in it, we might get double our return, right, or an order of magnitude improvement there. Because they will not just be maintained, but we can actually make them for a similar level of effort. Constantly improving and optimizing.

Probably should have a slide over here that summarizes. We talked about three problems. With skills as they grow, which are on security and governance, standardization, and and reuse to be able to work with them. And then maintaining the lifecycle going past sort of the the day one as we created.

Solution: treat skills as code (lines 263–278)

And and so my kind of last section here, I wanna make the case that the solution all those problems is to think about skills as code. And to bring in some core tools from the world of development into the way that we develop and build skills. And those are static analysis, dynamic tests, dependency management, security tooling, and observability. So me dig into how each of those might help. Skill development.

Tool 1 — Static analysis (lines 279–298)

Static analysis is in code the idea of inspecting some piece of code without actually executing it. And it ranges from sort of simple, stylistic things that can get bigger and bigger in linting, into deeper inspection of data flows and security analysis on it, into today in the modern world, a lot of agentic review. Of of your of your codes to sort of see whether you've built code that is deemed correct, that is deemed good. And in all of those cases, we don't x execute the code. We just run it.

And so conveniently, because we just inspect it, we can do the same for skills. You know, we can inspect it lightly or deeply as we want. We can use standard sort of known barometers of quality and safety or we can use things that are accustomed to our space. What this requires is it requires us to capture the definition of what good is. You know? What is a correct skill, a good skill? Skills are not as well structured as code, so it's a little bit more challenging, but still it's an opportunity to statically analyze those.

The Tessl version of this is Tessl review, which allows you to inspect by default, whether skills conform to the anthropic best practices. Allow you to increasingly customize that in your own code bases to say do they match your definition of good? With the added benefits of once you did analyze them, assign every skill a quality score. So now you also can communicate how well or how how like, what is the quality or how good is the skill?

Tool 2 — Dynamic tests (evals) (lines 299–334)

Dynamic tests are really probably the foundation of software quality. Right? And we've sort of seen animate the left side, we've, we've all, or like many of us have enough have been in the industry for long enough to have experienced the the dubious pleasure what happens when you write software without tests. Right? At the beginning, we do not write software with tests. And it feels very nice, and it works on your machine. And you don't bother with these sort of pesky tests. But then we've we've kind of come to appreciate, you know, in in, like, visceral pain, happens when you don't when you when you grow or continue down that path, and understand that you cannot scale software without tests.

And the same is true for skills. And so for skills, the comparison is evals. A means of assessing a skill, actually executing a skill, No. Let me take this back. Hold on. I've got a slightly different talk track on it.

So in dynamic tests, unlike static test, we actually execute the code be able to assess its correctness. And tests vary in complexity ranging from sort of simple unit tests that we might run locally that would run a small piece of our code in a specific way, all the way up to, like, three integration test that compose. Include more and more components and end to end tests that try to encompass the the bigger system. And each of those levels means more comprehensive testing and more time investments to be able to make those tests work.

The skill equivalent is AI evaluations. Defining scenarios that say, in this situation, this is how the agent should Here's the setup. Here's the task for the agent. 's the judgment about what good looks like. And just like with tests, you can make those scenarios more or less comprehensive as your needs. You can run skill with a lightweight model that just test whether this skill in isolation works with maybe a cheap and fast model just to know that you haven't regressed when you modified it, that it still works the same way it did before. You can expand out to think about project evaluations that test to the context of the entire project to say, have a whole bunch of skills here together, a whole bunch of together. Does it still work as planned? And I can go on to have comprehensive tests about, you know, how well do I I can agents deal with my system so I can use them, for instance, when a new model comes along? Or when I'm making a substantial change to my system.

So evals are foundations. And while we test, we have had the kind of the joyful experience of understanding what happens when you don't write test. We haven't seen those yet with evals. But the same is true here. We cannot scale without building those evals. And it's worth noting that evals and test scenario like, evals scenarios and test share a lot in common. If you first of all, like, if you rate good tests, then you get a lot of like, they're they serve as a very good kind of quality. Foundation, but that's test might just be a waste of time and money. Same is true for evals. You can write very useful ones, or you can write write ones that just waste your time. As we talked about, the scope can And we talked about the depth would vary.

If those are a big part of the Tessl platform, and so if you want to know how can you generate those types of scenarios, how can you run them, you can use the Tessl scenario Tessl eval run capabilities how do you manage them over time just like test management.

Tool 3 — Dependency management (lines 335–360)

Third bucket third bucket third tool I think we're we're missing is dependency management. And, you know, software composes, and it's amazing that it and it's the reason that we can build all the way from, you know, Linux onto frameworks onto, you know, our applications and our browsers. But software also means dependencies, and we all know how fun those are. And again, we sort of had the mileage of knowing that when you're using a dependency, changes in it might break your system, might make your system vulnerable. It might be an effort to upgrade to the system.

Skills also compose. Which is the reason they will be powerful, which is the reason we can build on top of them and expand. But it also means that they are dependencies as well. So what we like in the world of skills when we just copy dependencies around, copy skills around, is is we lack the ability to think of them as dependence management to or as dependencies.

We we need to learn from the lessons around composition that we've taken from the world of software applied the skills and give skills proper dependency management. When you think about versioning when you're releasing a new version of a skill, what does it mean? When you think about capturing a manifest with the different files that you might have, We talked about supply chain visibility, know which skills are being used. Where. And we also need to think about platform compatibility, which many many lot many, package managers provide to us. To be able to adapt a given dependency a given surrounding, specifically with skills, adapt a skill to many different types of harnesses. And again, this is a part of what Tessl provides as well. I need to work on the top track for this. Slide.

Tool 4 — Security tooling (lines 361–388)

So we covered static analysis, dynamic analysis, independence management. I think all of those revolve around the world of quality. As we talked about with concern, security is a is a real concern, a real kind of potential damaging path of skills as agents execute them. So skills so what happens? I have my speaker in those over here. Allow me to sort of redo this slide again.

It might not surprise you if I say that security has to be built into software development. That is the, core premise on top of which we build Snyk in the first place. And in the world of agentic development, that is more true than ever. It is it is a world that is moving faster than any team outside this development and agentic guidance. World can keep up with. And so if we want to keep our agents secure, if we wanna keep sort of our system secure, we have to build in some assessment of skills and some security tools for skills as a core part of how we develop with agents.

And the security tools that we need for skills are actually very, very similar to those that we need for for code. We should use static analysis to be able to identify and fix security flaws in skills. This should include also these sort of negligence or safety concerns, but otherwise there are quite similar. We need some supply chain security path so we need to know what is it that we're using. We might wanna delay when do we take a new update of a given skill. We definitely need to be able to track and the the rollout or sort of updates on new versions. And then we do need some red teaming. We need some ability to test, to dynamically test a skill to see, well, what happens when I try to break in, when I try to get you to go off the rails and behave in a nice fashion?

And so we need all of those things. It's good to see much all the apps sick [appsec] players leaning into this right now. We a Tessl integrated Snyk, and we will support other tools to be able to scan security paths to it. But you can see effectively all the, the apps of players, including Snyk, Socket, various others. Introduce some scale [skill] scanning capabilities. And I expect this world to grow Today, is still a little bit hard to know what is secure behavior. And that will probably continue to be a little bit hard because agents are less deterministic than than software So identifying what correct behavior and incorrect behavior is a bit more different.

Tool 5 — Observability (lines 389–410)

And then lastly, we can build great skills. We can test them. We can secure them. We can do all of that in the lab. But at some point, our skills have to meet the real world. And when they do, that is really oftentimes when a lot of the problems occur and a lot of the opportunities to improve. So just like software, you can build it all you wish, but a lot of the magic happens when you get into the ops world.

As we deploy them, we need to start observing how the skills behave in the in the wild. And for skills, especially for coding skills, runtime means what do people do with them with coding agents. Once we inspect those, when we look at the logs, when we look at the changes that those agents produce, there's a lot of gold that we can extract out of that. We can extract real world scenarios so that our tests are better, our scenarios represent what the agents actually do. We can mine them for for gaps, for cases in which they fail to do something so that we will know the limits of our agents and maybe do something about it. And then we can look at how users have overcome problems in the specific cases, mind those for opportunities for new skills. Right? Okay. This is how someone overcame them. Can I package that up for the rest of the team?

At Tessl, we're still newer to the world of automating this. We've been investing a fair bit over here. So if you're interested in this again, I need a better CTA for this. Stop by the booth and talk to you about it.

The CDLC (lines 411–428)

So it all together. So so this this core tools, they need to come with a development process, with a methodology around how do we combine them as we evolve. Want to generate good skills. We want to create the tests the evaluations, whether static or dynamic, to build it. Then want to optimize based on the learnings. We're ready, we want to distribute them with proper package management observe what has happened. And we want to do that while maintaining security and quality. Across the board.

We call this the context development life cycle or the CDLC, we think that the right future is for humans to operate mostly on the CDLC. Mostly creating the context that guides the agents, while the agents should handle the SDLC end to end.

Let's wrap up. We're starting to see the foundations of AI native development, and what does the software stack look like. All of this is building on top of models, but the units that we're building start at tools and capabilities we make available to the agent. We evolve into skills which hopefully I've made some case is the new code. It evolves into harnesses, which I think of more as frameworks. These are not something that you'd see every developer on the team building. It is something that probably many organizations with pick. Customize or even create their own. About how do you want to invoke, have the agents operate, which in turn composed into factory lines and factories where I also think we will see some repeatable patterns about what we build, but many of those are still still many of these kind of wars or sort of plans and methodologies are still being created in real time.

Wrap-up & the Tessl agent (lines 429–470)

Okay. One more thing. As as we go through the presentation, I increasingly practice less the the the top track to it. So so with the with the the new development we think there's a lot to learn. There are a lot of changes There happening very, very rapidly. And we'd like to help. And a part of our commitment at I feel like it's all the I'll just sort of speak through it, but any to sort of think through the talk track here in general.

As we seek to to help all of us develop these assets better, we think they deserve their own development agent. And that is exactly what we're starting to build with the agent, which I called Tessl here. Totally uncoordinated with anybody else. And what this is is is is a vertical agent to help you develop skills, harnesses, and more. And Tessl's You know what? Maybe I'll sort of skip this right now because I don't have it. I'll sort of say to you just more broadly is that we think of of a of the Tessl agent as something that composes skills, like, that uses the Tessl tools to be able to build to develop these different skills like we're doing with the skill optimizer and the likes. It includes all of these skills that we've been packaging and building. The expertise to say, well, what should you do when I want to create a skill when I want to optimize it, when I wanna create awareness, when I want to create a factory, this is what I would build. And then all of that is wrapped in a harness that has the right constraints. Has the right, UX for it so that people can engage with it pretty well.

And we, want that to be available to you across three primary modalities in the in the across the context development life cycle. Locally as you are building skills, optimizing skills, modifying them, using them locally. The pipeline. When you are reviewing changes, when you are collaborating on skills, you're making sure that your skills remain up to date from other changes and make sure that they are that changes to them do not make them regress. And in the in an orchestrated fashion, in the Tessl control center. Which we can say, hey. We've identified out of logs opportunities to make changes or use have reported changes, etcetera, etcetera. We can trigger the creation of new pipelines. All of those will be performed by the Tessl agent. As part of it. And access is still controlled. We're still getting started with this. Stop by our booth. To find that out.

So to close off, A native development is starting to form and firm up. And I, for one, am very excited about this. And at Tessl, we believe that creating sort of the new development methodology is creating our new craft, and that is a community activity. And that's why we invest so much in AI native dev con and so excited to be building this together with all of you. So I hope you enjoy the next two days over here. And I'd encourage you to not just listen and learn, but also to share with everybody around you have you learned what have you improved, so we can all build in at development practices. The sort of new brave new era together. Thank you.

Okay. A few things are fairly obvious. So I thanks for the dry run. Yep. A few things. While there was a wording intense, dog.

evals