Shipping AI-Generated Code That Won't Hurt You (Much)

Transcript

Okay, so next we have Everett Henbrand. He's the CEO of runtime verification and Everett will teach us how to use AI based uh workflow. Sorry, how to use how to do secure vibe coding. Is that working? That working? Okay. uh familiar topic I guess so um but I like the la last presentation a lot I think I agreed a lot of the points there so secure vibe coding or as we submitted the top shipping AI generated code that won't hurt you I'm ever hilenbrandt I am the CEO of runtime verification been in web 3 for a while a lot of secured

assets um we offer a variety of services that probably all of you all are familiar with we have several tools we've developed that we use in our audits and our quality assurance services um and we do some other verification work when we find more interesting projects to work on as well on the side. Uh we independent we don't well we do have a central AI initiative at runtime verification uh with some specific things independently a lot of the developers at runtime verification are using AI of course in our code development and software quality assurance workflows uh but we're kind of doing it in an evaluative manner I guess. Um, so security, it's really one small word and it's all about advanced prompt engineering and red team cyber

agents and autonomous threat intelligence oracles and zero. No, these are all generated with AI. So they may be good for a pitch deck, but really the one word that is important is secure. You put the word secure in your prompt when you're asking it for how to generate your application. Probably not, right? Um, yeah, probably not that simple. So why doesn't this work? The LLM does produce code, right? But we don't have any confidence that the code it produces is correct. Right? So that's kind of the the key problem there. And so what is secure code? It is code with a body of evidence about the correctness of that code.

So correctness, we all know the code behaves as expected, which is kind of a pretty big definition there. uh and a body of evidence that's tests, specs, human review, audit report, full verification, fuzzing campaigns, all these other things that come along with the code that produce that evidence that the code is correct. So, I needed I asked, you know, here's an example. I need a meme from chat GPT about someone doing something with a yes sir attitude where it just does whatever you want and uh it didn't exactly do what I want. I had to suggest stop it and suggest something else. Eventually came up with this. So, fill the dishwasher and it fills the dishwasher with some water or something. So that's kind of the that's kind of the problem, right? Like you ask AI, hey, make this application for me and it goes off on the wrong direction

and just kind of keeps going that way. As soon as it makes its first mistake, it's, you know, it's going the wrong way. So what is correctness? Correctness, as you know, you must know the intention of the application, which is set by a human. So you create a specification based on that intention. It's got English, it's got math, it's got sigas in it, it's got vibes in it. You know, it's it's expressing the desire of the human. And you you have to have at least one sigma and you have bonus points for an element of symbol in there. But it requires thinking about the goal of the project, right? Which is the key thing that is humanoriented, I guess, unless you have some super advanced cybernetic AI agent that's doing your thinking for you. Really thinking is too much to ask. And so can

we do better? Well, the key insight is let Google think for you. So that's a joke by the way, but it's a joke by this this artist who has a song called Google Does My Thinking for Me. So, okay. What's a body of evidence? It's a list of activities to show that the code implements the specification. So, there's computer validation, that's testing, CI is green, static analysis, all reported findings are false positives, formal verification, the proofs pass, fuzzing, campaign logs, the run counts, etc., how much compute you threw at it.

And then the human validation, there's an audit report. Maybe it collects all of that body of ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev ev evidence and puts it together and presents it to the user in a way that actually is digestible or marketable usable as that body of evidence. And so maybe you can do some agent validation as well as part of that body of evidence. We ran the almanac scanner or we tried the Olympics tool or something like that and we say this is the results that we got from it. Again, you have to report those so that other people can see and say hey actually yeah it makes sense what you did to produce

that body of evidence. So here's your AI agent validation approach right there. So bundle all that up until it's enough to convince people that you're ready to go to TGE whatever that means. So it's about the journey right and this you know that's the specification the requirements the implementation and code the test the fuzzing campaign the verification the audit that's a long journey which the only part that's actually shipped is the code that's the only part that actually goes to deployment. We also talked about monitoring systems. Those are shipped as well. That's not in this because we do mostly pre-eployment security. Um, but the only part that's actually shipped is often even less than 25% of the time if you're talking about developing code in

a sane manner. And so really when the big bad wolf is chasing Little Red Riding Hood, he doesn't just eat her on the trail the way there. He waits and he watches until she gets all the way to grandma's house because he enjoys the thrill of the chase there. It's about the journey. Okay. So if only we knew how to develop secure code, right? So chat GBT, what is a standard agreed upon way of developing safety critical software systems with few faults? Thought for 19 seconds, which is longer than I can think. So this isn't literally one single global method, but it immediately came up with Vodel, V cycle, right, which I'm sure a lot of the folks here are familiar with if you have a formal verification background. And the key word that I want

to call out here, so the one small word that I think is important for secure vibe coding is process. So if only someone had studied this, I don't maybe some other industry had some idea of how how we could approach this, but it's this it's the V model, right? You start with your specifications, your requirements, uh a detailed design, you go into implementation phase, then you do some sort of testing and integration, system verification, validation, operation and maintenance we call monitor. So different words, different industries, but every industry has kind of landed on this. Start from what it is that the human intends, refine that into an implementation, build a body of evidence that their correct operation of the protocol is happening on the other

end. This is far too much thinking at this point, so save us. But this is supposed to be an AI co talk, right? And so the small the small word that I encourage you to think about is processes. So you design your processes to be robust because the idea is that you should be able to input AI or human slop without risking the final outcome of the product. That's how your processes should be designed. And then you only want to use AI in an additive way for your process, not a replacement way. So discover where AI is actually helpful. Some repetitive tasks, some discovery tasks, finding things, validating stuff. You know, we have a handful of different workflows that we use AI agents for when we're doing software quality assurance and drop it

where it's not working because it's slowing you down. People are trying these things and it's just not actually speeding it. It's fun. It's like a video game, right? You're sitting there and you're like, oo, can I get the AI agent to do this thing and this thing? Four hours go by, you're like, well, I probably could have coded that in three hours. I don't know. That's my experience. But I do use I personally do use AI for vibe coding some applications exclusively and other applications I write all the code myself. So, I don't know. I think it really depends. Um, and double check its work. I think that's really the key step. You know, I I very rarely, you know, you give you go into plan mode in Claude Code. That's what I use, Claude Code. Have it make a plan for me. I iron out the plan with it.

Sometimes I even spend 30 minutes going back and forth with it on the plan. I press go. I don't walk away at that point. I watch. I watch what it's doing, the keystrokes it's putting in, the changes it's making to the code, and I stop it when I notice that it's violating some of my design decisions about that particular application. So, so talk a little bit about the process. You know, this is kind of vodel adjusted for web 3 and my own crazy, you know, whatever lack of sleep brain a couple days ago. So, you probably should write your white paper yourself. That's my I mean, maybe you shouldn't. I don't know.

It depends on your goals. Um, but you can ask AI, am I missing any obvious design flaws in my white paper? Are there any features you think I should include in this version of the protocol that are not in the white paper? Uh is the language confusing or ambiguous? And you check the results and you adjust your white paper, right? And specifications, same sort of deal. Please ask the AI like, you know, generate a spe a fleshed out specification of the white paper complete with invariance and descriptions of actors and their actions and blah blah blah blah. Are the behaviors described in the white paper missing here? Are the detailed components actually implementable and testable? Are there any contradictions in the specification? So these are just example prompts that you could use to try to refine your specification with an AI and they're exactly the same prompts

you would give to an engineer. Same with requirements. Refine that to a list of requirements, invariance, properties about the protocol that need to be uh you know true. See if any of them are mutually contradictory. You know again back and forth the AI agent checking the results and ask your engineer also to look at it. Finally refine to a design as well. you know, please generate an architectural description of the contracts. Um, is everything from the specification actually reflected in the design? Are the requirements going to be satisfiable with this design? These again questions from the V model that the AI agent can help you to answer quickly and again check the results.

Finally, write the code. And you know, I I have found that giving AI like the the cart launch prompt like write the code for me doesn't work. That's my experience. They can't go very long without being managed basically. Um, and so, you know, implement it component by component. Please make me the arithmetic system. Please make me the vaults. Please make me the UI. P, you know, whatever it is, the different components that put together the whole system. Tests, fuzzing, campaign verification. Same sort of deal. Please write me the test, the fuzzing conditions, the fuzzing tests, the verification conditions that reflect the requirements of the protocol for uh validating the correct operation of it. And then actually run the tests. That's the key, right? You got to run the tests and check the results. And finally, you

bundle all that up together into a body of evidence of the correct operation of the protocol and you ship that off to your auditor. Right? So that's the that's the whole cycle, but where you're introducing AI as individual little helpers along the way for the places that it can be strong. Okay. So some final thoughts and I think I'm wrapping up early, which is probably good. Uh does this sound too prescriptive? That's the point. process is about having a prescriptive procedure which results in good outcomes even if you have crappy ingredients right and the crappy ingredient here is of course AI slop vibe coding this is my opinion is for project managers right I think that what in my experience what I've seen with developers trying to vibe code is they

don't use the tools correctly you know they don't they don't actually go about uh treating it like something that they have to project manage they instead you know treat it as something that is like, "Oh, I want you to do this." And they don't think about actually refining the specification and getting it to where the vibe coder or the the AI agent is able to actually make progress on the goal. And that's because they don't have experience with, hey, could you implement this for me? You come back a week later and you're like, oh, I actually implemented this other thing. It's like, well, that wasn't what we discussed about, but there was that missing connection between you and your intern or whatever. So, just as a little exercise, think about how long would you leave a senior engineer alone with a prompt. You know, you might talk to them

once a week, give them a prompt, they go for a week, then you come back, you have to make some correction to their prompt a week later. An intern maybe once a day. An AI agent once every 30 minutes or so at most, I would say. That's my experience at least. So, and then what if your computer gets thirsty? Well, just give it some more water. We don't need crops. So, there you go. Uh, you want to try it? We have this tool, symbolic.dev. It's a debugger. We're going to be integrating AI features into it for automating little bits of the audit and code development process Q1 2026. And then I'll just remind everyone, it's everyone's responsibility to respond to the growing rise of fascism around the

globe. So think about ways you can do that in your life, like installing signal or leaving Twitter. Thank you. Any questions? >> Okay. And if not, let and thank Everett again. >> Oh, sorry. >> So, uh, yeah. Okay. So when you're using AI in the development like there's the delta between using AI for these very specific use cases um kind of like what

you touched on I think at the very end with integrating it into your um IDE system or using it for these more general processes where you just like give it an arbitrary goal agentic style and it completes it. Um what do you think about like the balance of those and where the two of those systems the very specific goal and task specific AI versus more general approaches are better for different security areas. Well, I think the I my so I am not an expert on this by any means, right? I'm using it. I'm experimenting. I'm seeing where it's working and I'm trying to be very clear about dropping where it doesn't feel like it's working for me.

And so that doesn't mean I've tried everything, right? But my impression is when I try AI to do something that would take a while, right, it kind of it goes off the rails at some point. And so it's better to give it repetitive tasks that do take me a little bit of time. like maybe this takes me 20 seconds per edit or something that I have to do and there's a bunch of edits that I need to do or I need to go and discover different part of a codebase and but there's specific queries I want to know about that whole part of the codebase. Okay, go find every one of those things about every one of those functions or something for me. And that is something where you can chunk up your inputs.

That's basically what it boils down to me for me is like don't just use the fact that you have a massive context window to just throw the whole repository in. actually snip out the pieces of code that are interesting and ask it specific queries about each one and have it think for 30 seconds about each one independently instead of just saying hey go look at all the functions there and give me all the annotations or something like that. So that's kind of been my experience is giving it smaller more discovery oriented tasks and then you know doing a lot of planning ahead of time with it before actually implementing those are the things that have worked for me. So >> yeah. No, I was just curious because you mentioned like giving an AI prompt every 30 minutes and that seemed incredibly long, but no, this use case of

>> segmenting it down and giving it maybe a tenth of its context window makes a lot more sense. >> I probably have never left it alone for 30 minutes at a time. >> They get weird after about 10. >> Yeah, 10. 10 maybe. >> Any other questions?